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DATA TRANSMISSION APPARATUS, 
SYSTEM AND METHOD, AND IMAGE 
PROCESSING APPARATUS 



BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a data transmission 
apparatus, system and method and an image processing 
apparatus, and more particularly, to a data transmission 
apparatus, system and method and an image processing 
apparatus used in a case where an image providing device 
such as a digital camera is directly connected to an image 
processing device such as a printer via a serial interface 
based on, e.g., the IEEE 1394 standards. 

2. Description of Related Art 

Various types of systems which transfer data to a printer 
via a bus are known. For example, a known technique is to 
output data from a computer to the printer by using a defacto 20 
standard interface such as a SCSI (Small Computer System 
Interface) or Centronics interface. 

In other words, the printer is connected to a personal 
computer (PC) used as a host device via a parallel or serial 
interface such as a Centronics or RS232C interface. 25 

Further, digital devices as image providing devices such 
as a scanner, a digital still camera and a digital video camera, 
are also connected to the PC. Image data inputted by the 
respective digital devices is temporarily stored in a hard disk 
or the like on the PC, then processed by an application 
software program or the like on the PC and converted into 
print data for the printer, and transferred via the above 
interface to the printer. 

In the above system, the PC has driver software programs, 
respectively, for controlling the digital devices and the 
printer. The image data outputted from the digital devices is 
held by these driver software programs in data format which 
can be easily handled and displayed on the PC. ITie stored 
data is converted into the print data by an image processing 
method in consideration of image characteristics of the input 
and output devices. 

Today it is possible for a new interface such as an 
interface based on the IEEE 1394 standards (hereinafter 
referred to as "1394 serial bus") to directly connect an image 
providing device and a printer. In case of directly connecting 
the image providing device to the printer by the 1394 serial 
bus, an FCP (Function Control Protocol) operand may 
include print data. Further, in the 1394 serial bus, a register 
area for may be provided such that data transfer is performed 
by writing data into the register area. 

Further, the 1394 serial bus has an isochronous transfer 
mode and an asynchronous transfer mode. Time-restricted 
data, e.g., real-time data, is transferred by isochronous 
transfer, while simple data transfer is performed by asyn- 
chronous transfer. 

Further, in a case where node(s) is added or deleted on the 
1394 serial bus, bus reset is performed for reconstructing the 
bus. 

As described above, the image data outputted from the 
image providing device is converted into print data by the 
PC and print-outputted by the printer, accordingly, even if 
the image providing device and the printer are directly 
connected, printing cannot be performed without the PC. A 
video printer which directly print-outputs image data out- 
putted from a digital video camera is known, however, even 
in case of using this printer, connection is made only 



between specific devices. There is no video printer which is 
directly connected to a number of image providing devices 
for general printing purposes. That is, it is impossible to 
directly send image data from the image providing device to 
a printer for printing, by utilizing a function to directly 
connect devices, which is characteristic of the 1394 serial 
bus or the like. 

In the above method which directly connects the image 
providing device to the printer with the 1394 serial bus and 
includes print data into an FCP operand, the control com- 
mands cannot be separated from the print data. Further, in 
this method, the transfer efficiency is low since a response is 
always required with respect to a command. The above 
method providing a register area for data transfer requires 
processing to determine whether or not data can be written 
into the register area at every data transfer. Accordingly, the 
overhead of the determination processing is great, which 
degrades the transfer efficiency. 

Further, in the isochronous transfer for transferring time- 
restricted data, if a transfer error occurs, error recovery in 
certain data unit is difficult. 

Further, if the above -described bus reset occurs, data 
transferred at that time is lost, or information indicating that 
data has been received is not correctly transmitted. 

SUMMARY OF THE INVENTION 
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The present invention has been made to solve the respec- 
tive or all of the above problems, and has its object to 
30 provide a data transmission apparatus, system and method 
and an image processing apparatus, appropriate for directly 
connecting a host device with a target device by using a 
serial interface based on the 1394 serial bus or the like and 
processing image data, directly sent from the host device to 
35 the target device, by the target device. 

Further, another object of the present invention is to 
provide a data transmission apparatus, system and method 
and an image processing apparatus which separate control 
commands and data and attain high transfer efficiency. 

Further, another object of the present invention is to 
provide a data transmission apparatus, system and method 
and an image processing apparatus which recover a transfer 
error even if the transfer error occurs in isochronous transfer. 
45 According to the present invention, the foregoing objects 
are attained by providing a data transmission method of host 
and target devices which are connected by a serial bus, said 
method comprising the steps of: sending a command from 
said host device to said target device; returning a response 
5Q from said target device to said host device; and transferring 
data by isochronous transfer from said host device to said 
target device if it is determined based on the response that 
a transfer error has not occurred, and retransferring the data 
if it is determined based on the response that the transfer 
55 error has occurred. 

Further, the foregoing objects are attained by providing a 
data transmission apparatus cotmected to a serial bus, com- 
prising: command transmission means for transmitting a 
command to a target device; reception means for receiving 
60 a response returned from said target device; and transfer 
means for transferring data by isochronous transfer to said 
target device if it is determined based on the response that 
a transfer error has not occurred, and retransferring the data 
if it is determined based on the response that the transfer 
65 error has occurred. 

Further, the foregoing objects are attained by providing a 
data transmission apparatus cormected to a serial bus, com- 



02/20/2004, EAST Version: 1.4.1 



us 6,61 

3 

prising: recq)tion means for receiving a command and data 
sent from a host device; transmission means for sending a 
response to said host device; and detection means for 
inserting information indicative of occurrence of a transfer 
error into the response if detecting the occurrence of transfer 
error in data transfer. 

Further, another object of the present invention is to 
provide a data transmission apparatus, system and method 
and an image processing apparatus which perform proper 
data transfer even if bus reset occurs. 

According to the present invention, the foregoing object 
is attained by providing a data transmission method of host 
and target devices which are connected by a serial bus, said 
method comprising the steps of: sending a command from 
said host device to said target device; returning a response 
to the command from said target device to said host device; 
transferring data of a predetermined unit from said host 
device to said target device, based on buffer information 
included in the response; and retransferring a part of the data 
of the predetermined unit when bus reset has occurred. 

Further, the foregoing object is attained by providing a 
data transmission apparatus connected to a serial bus, com- 
prising: command transmission means for transmitting a 
command to a target device; reception means for receiving 
a response to the command, returned from said target device; 
transfer means for transferring data of a predetermined unit 
to said target device, based on buffer information included in 
the response; and retransfer means for, ff bus reset has 
occurred, retransferring a part of the data of the predeter- 
mined unit transferred when the bus reset has occurred. 

Further, the foregoing object is attained by providing a 
data transmission apparatus connected to a serial bus, com- 
prising: command reception means for receiving a command 
sent from a host device; transmission means for transmitting 
a response to the command, to said host device; transfer 
means for transferring data of a predetermined unit to said 
host device, based on buffer information included in the 
response; and re-reception means for, if bus reset has 
occurred, re-receiving a part of the data of the predetermined 
unit transferred when the bus reset has occurred. 

Other features and advantages of the present invention 
will be apparent from the following description taken in 
conjunction with the accompanying drawings, in which like 
reference characters designate the same name or similar 
parts throughout the figures thereof. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in 
and constitute a part of the specification, illustrate embodi- 
ments of the invention and, together with the description, 
serve to explain the principles of the invention. 

FIG. lA is an explanatory view showing a general con- 
struction of a system to which the present invention is 
applied; 

FIG. IB is a block diagram showing an example of a 
network system constmcled with an IEEE 1394 serial inter- 
face; 

FIG. 2 is a block diagram showing the construction of the 
IEEE 1394 serial interface; 

. FIG. 3 is an explanatory view showing address space of 
the IEEE 1394 serial interface; 

FIG. 4 is a cross-sectional view showing a cable for the 
IEEE 1394 serial interface; 

FIG. 5 is a timing chart explaining a Data/Strobe Link 
method; 
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FIGS. 6 to 8 are flowcharts showing a procedure of 
network construction in the IEEE 1394 serial interface; 

FIG. 9 is a block diagram showing an example of the 
network; 

^ FIGS. lOA and lOB are block diagrams explaining bus 
arbitration; 

FIG, 11 is a flowchart showing a procedure of the bus 
arbitration; 

FIG. 12 is a timing chart showing transitional statuses in 
asynchronous data transfer; 

FIG, 13 is a diagram showing a packet format for the 
asynchronous transfer; 

FIG, 14 is a timing chart showing transitional statuses in 
15 isochronous data transfer; 

FIG. 15 A is an example of a packet format for the 
isochronous transfer; 

FIG. 15B is a table showing the details of packet format 
fields for the isochronous transfer in a 1394 serial bus; 

FIG. 16 is a timing chart showing transitional statuses in 
data transfer on the bus when the isochronous transfer and 
asynchronous transfer are mixedly performed; 

FIG. 17 is a schematic view showing the IEEE 1394 serial 
interface in comparison with an OSI model; 

FIG. 18 is an explanatory view showing the basic opera- 
tion of a LOGIN protocol; 

FIG. 19 is an explanatory view showing connection status 
in the IEEE 1394 serial interface; 
30 FIG. 20 is a timing chart showing the flow of log-in 
operation; 

FIG. 21 is a schematic view showing a CSR preparing 
respective devices; 

FIG. 22 is a flowchart showing LOGIN processing in a 
host device; 

FIG. 23 is a flowchart showing LOGIN processing in a 
target device; 

FIG. 24 is an explanatory view showing a case in con- 
sideration of a device v/ithout the LOGIN protocol; 

FIG. 25 is a schematic view showing the IEEE 1394 serial 
interface in comparison with an OSI model, in the second 
embodiment; 

FIG. 26 A is a table showing functions of a CSR archi- 
45 lecture of the 1394 serial bus; 

FIG. 26B is a table showing registers for the 1394 serial 
bus; 

FIG. 26C is a table showing registers for node resources 
of the 1394 serial bus; 

FIG. 26D is an example of a minimum format of a 
configuration ROM of the 1394 serial bus; 

FIG. 26E is an example of a general format of the 
configuration ROM of the 1394 serial bus; 

FIG. 27 A is a timing chart showing a re quest -response 
protocol with read, write and lock commands, based on the 
CSR architecture in a transaction layer; 

FIG. 27B is a timing chart showing services in a link 
layer; 

FIG. 28 A is a timing chart showing an operation example 
of a split transaction; 

FIG. 28B is an explanatory view showing transitional 
statuses of transfer by the split transaction; 

FIG, 29 is an explanatory view showing an AV/C trans- 
65 action in the 1394 serial bus; 

FIG, 30 is an example of the packet format for the 
asynchronous transfer including an FCP packet frame; 
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FIG. 31 is an example of the structure of an AV/C 
comnaand frame; 

FIG. 32 is an example of the structure of an AV/C 
response frame; 

FIG. 33 is a schematic view showing a register map; ^ 

FIG. 34 is an explanatory view showing the flow of 
frames from an image providing device to the printer; 

FIG. 35 is an explanatory view showing the construction 
of a format register; jO 

FIG. 36 is an explanatory view showing the detailed 
construction of a status register of a common register group; 

FIG. 37 is an explanatory view showing the details of 
information held in a register GLOBAL of a common 
register group; 15 

FIG. 38 is an explanatory view sho\\ang the details of 
information held in a register LOCAL of the common 
register group; 

FIG. 39 is an explanatory view showing the details of 
information held in a register format[l]; 

FIG. 40 is an explanatory view showing the details of 
information held in a register format[2]; 

FIG. 41 is a table showing commands and responses to the 
commands; 25 

FIG. 42 is an example of an image data formats supported 
by the DPP protocol; 

FIG. 43 is a timing chart showing the flow of format 
setting processing; 

FIG. 44 is a timing chart showing the flow of data-transfer 
method setting processing; 

FIG. 45 is an explanatory view showing a register map of 
registers necessary for transfer method 1 and transfer 
method 2, in address space of the 1394 serial bus; 35 

FIG. 46 is an example of a data packet frame; 

FIG. 47 is an example of the structure of a data header; 

FIG. 48 is an explanatory view showing data packet frame 
processing in the printer in block transfer; 

FIG. 49 is a timing chart showing commands and 
responses FreeBlock in the transfer method 1; 

FIG. 50 is a timing chart showing the flow of data transfer 
in the transfer method 1; 

FIG. 51 is a timing chart showing the flow of data transfer 45 
in the transfer method 2; 

FIG. 52 is a timing chart showing the commands and 
responses FreeBlock in the transfer method 1, in detail; 

FIG. 53 is a timing chart showing a commands and 
responses WriteBlock in the transfer method 1 and the 50 
transfer method 2; 

FIG. 54 is a timing chart showing the commands and 
responses WriteBlock in the transfer method 1 and the 
transfer method 2, in detail; 

FIG. 55 is a timing chart showing the flow of WriteBlock 
error processing upon occurrence of bus reset; 

FIG. 56 is an explanatory view showing the construction 
of command registers, response registers and data registers 
of the image providing device and the printer, in a PUSH 
Large Buffer Model; 

FIG. 57 is a timing chart showing the flow of operation in 
a PUSH buffer model between the image providing device 
and the printer; 

FIG. 58 is an example of a data packet in a data frame; 55 

FIG. 59 is an explanatory view of the relation between the 
data register and the buffer of the printer; 
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FIG. 60 is an explanatory view showing the construction 
of the command registers, the response registers and the data 
registers of the image providing device and the printer, in a 
PULL buffer model; 

FIG. 61 is a timing chart showing the flow of operation in 
the PULL buffer model between the image providing device 
and the printer; 

FIG. 62 is an explanatory view showing the relation 
between the data register and the buffer of the image 
providing device; 

FIG. 63 is an explanatory view showing memory alloca- 
tion for command registers and response registers for flow 
control; and 

FIG. 64 is a liming chart showing the flow of print 
processing. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

Hereinbelow, a data transfer method according to an 
embodiment of the present invention will now be described 
in detail in accordance with the accompanying drawings. 

FIG. lA shows an example of general construction of a 
system to which the present invention is appUed, where a PC 
103, a printer 102 and a digital video camera (DVC) 101 are 
connected via a 1394 serial bus. ITien the outUne of the 1394 
serial bus will be described below. 
[Outline of 1394 Serial Bus] 

With the appearance of general digital video cam recorder 
(VCR) and digital video disk (DVD) player, there is a need 
for transferring realtime and large amount data such as video 
data and audio data (hereinafter referred to as " AV data"). To 
transfer AV data in reaUime to a personal computer (PC) or 
other digital devices, an interface capable of high-speed data 
transfer is required. The 1394 serial bus has been developed 
from the above point. 

FIG. IB shows an example of a network system con- 
structed with a 1394 serial bus. This system comprises 
devices A to H, and the devices A and B, the devices A and 
C, the devices B and D, the devices D and E, the devices C 
and F, the devices C and G, and the device C and H are 
respectively connected by a twisted pair cable for the 1394 
serial bus. These devices A to H may be computers such as 
a personal computer, or most computer-peripheral devices 
such as a digital VCR, a DVD player, a digital still camera, 
a storage device using a storage medium such as a hard disk 
or an optical disk, a monitor such as a CRT or an LDC, a 
tuner, an image scanner, a film scanner, a printer, a 
MODEM, and a terminal adapter (TA). 

Note that the printing method of the printer may be any 
method, e.g., a laser-beam printing, an electrophotographic 
method using an LED, an ink-jet method, a thermal-transfer 
method of ink melting or ink sublimation type and a thermo- 
sensitive printing method. 

The connection between the devices may be made by 
mixedly using a daisy chain method and a node branching 
method, thus realizing high-freedom of connecting. 

The respective devices have an ID, and they conslmct a 
network by identifying each ID within a range connected by 
the 1394 serial bus. For example, the devices respectively 
take a relaying role only by daisy-chain connecting the 
devices with cables for the 1394 serial bus, thus constructing 
a network. 

As the 1394 serial bus corresponds to Plug and Play 
fiinction, it automatically recognizes a device connected to 
the cable, thus recognizes connection status. In the system as 
shown in FIG. IB, when a device is removed from the 
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network, or a new device is added to the network, the bus is CSR core, the register of the serial bus, the configuration 

automatically reset (i.e., the current network constructing ROM and the unit space. 

information is reset), and a new network is constructed. This The 1394 serial bus has the construction as described 

function enables realtime setting and recognition of network above. Next, the features of the 1394 serial bus will be 

construction. 5 described in more detail. 

The 1394 serial bus has a data transfer speed defined as [Electrical Specification of 1394 Serial Bus] 

100/200/400 Mbps. A device having a high transfer speed ^ ^^^^^ ^ cross-section of the cable of the 1394 

supports a lower transfer speed, thus maintaining compat- ^'}^^ f'^; ^^^^^ ^^^^^ comprises two sets of 

ibility. As data transfer modes, an asynchronous transfer ^^^^ P.^^^ ^'^""^ ^""^^ power-source Imes. TTiis 

J /Arng\ r * r • I. J * i_ construction enables power supply to a device which lacks 

mode (ATM) tor transiernng asynchronous data such as a lo J . ^ ,^ . , j j j 

. r jr. c ■ a power source, or a device where a voltage is degraded due 

control signal, an isochronous transfer mode for traiisferring ^o a failure or the like. The direct-current voltage supplied by 

isochronous data such as realtime AV daU are availab e In power-source lines is 8 lo 40V; the current is maximum 

data transfer, within each cycle (generally 125 //s/cycle), a ^ 5 ^ ^^^^e that in the standards for soncaUed DV cable, four 

cycle start packet (CSP) mdicating the start of cycle is 1^^^^ ^^cept the power-source fine construct the cable, 

transferred, and then asynchronous and isochronous data are 15 [DS-Link] 

mixedly transferred such that the isochronous data transfer piG. 5 is a timing chart explaining a DS-Link (Data/ 

is transferred prior to the asynchronous data. Strobe-Link) method as a data transfer method. 

FIG. 2 shows the construction of the 1394 serial bus, as The DS-Link method, appropriate for high-speed serial 

a layer structure. As shown in FIG. 2, a connector port 810 data communication, requires two sets of two signal lines, 

is connected to a cotmector at the end of a cable 813 for the 20 That is, one of the two sets of twisted-pair signal lines is 

1394 serial bus. A physical layer 811 and a link layer 812 in used for sending a data signal, and the other one set of 

a hardware unit 800 are positioned as upper layers with twisted-pair signal lines is used for sending a strobe signal, 

respect to the connector port 810. The hardware unit 800 On the receiving side, an EXCLUSIVE- OR between the 

comprises interface chips. The physical layer 811 performs data signal and the strobe signal is obtained so as to generate 

coding, connection-related control and the like, and the link 25 ^ ^1°^^ signal. In the DS-Link transfer, it is unnecessary to 

layer 812, packet transfer, cycle-time control and the like. ^ ^^^^^ signal into a data signal, therefore, transfer 

In a firmware unit 801, a transaction layer 814 manages efficiency is higher than that in other serial-data transfer 

data to be transferred (transaction data), and outputs com- methods. Further, as a clock signal is generated from the data 

mands Read, Write and Lock. A management layer 815 in ^'^''^} ^"^/^^ ^fJ'l^^ ^ .P^^^ ^^P (^^L) 

the firmware unit 801 manages connection statuses and ID's 30 ^ ^^'"'^^'^i'^^ '"T ^w'^' 

- J . . ji . I. -i^nA ■ 1 u of a controller LSI. Further, m the DS-Link transfer, it is 

of the respective devices comiected to the 1394 serial bus, unnecessary to send information indicative of idle status 

thus manages the network construction. The above hardware ^^en there is no data to be transferred, therefore, a trans- 

and firmware umts substantially constructs the 1394 serial reiver of each device can be set in a sleep status, which 

reduces electric consumption. 

In a software unit 802, an application layer 816 differs in 35 [Bus-Reset Sequence] 

software used by the system, and the data transfer protocol - The respective devices (nodes) connected to the 1394 

indicating how to transfer data on the interface is defined by serial bus are provided with a node ID, and are recognized 

a protocol such as a printer protocol or an AVC protocol. as nodes constmcting the network. For example, when 

FIG. 3 shows address space of the 1394 serial bus. All the increase/decrease of the number of nodes due to connection/ 

devices (nodes) connected to the 1394 serial bus have a 40 disconnection or power ON/OFF status of network devices, 

unique 64 bit address. The 64 bit address is stored in a i.e., network construction changes and it is necessary to 

memory of the devices. Data communication with a desig- recognize a new network construction, the respective nodes 

nated destination device can be performed by always rec- detect the change of network construction, send a bus-reset 

ognizing the node addresses of the transmitting- and signal onto the bus, and enter a mode for recognizing the 

receiving-side nodes. 45 new network construction. The detection of change of 

Addressing of the 1394 serial bus is made based on the network construction is made by detecting change of bias 

IEEE 1212 standards, such that first 10 bits are allocated for voltage at the connector port 810. 

designating a bus number, then next 6 bits are allocated for When the bus- reset signal is sent from one node, the 

designating an node ID. physical layer 811 of the respective nodes receives the 

48-bit address used in the respective devices are divided 50 bus-reset signal, and at the same time, notifies the link layer 
into 20 bits and 28 bits, and utilized in the unit of 256 812 of the occurrence of bus reset, and forwards the bus- 
Mbytes. In the initial 20-bit address space, "0" to reset signal to the other nodes. When all the nodes have 
"OxFFFFD" is called a memory space; "OxFFFFE", a private received the bus-reset signal, a bus-reset sequence is started, 
space; "OxFFFFF", a register space. The private space is an Note that the bus- reset sequence is started when the cable is 
address freely used in the device. The register space, holding 55 attached/detached, or the hardware unit 800 has detected 
information common to the devices connected with the bus, network abnormity or the like. Further, the bus-reset 
is used for communication among the respective devices. sequence is also started by a direct instruction to the physical 

In the register space, the initial 512 bytes are assigned to layer 811 such as host control by a protocol. As the bus-reset 

a register core (CSR core) as a core of a Command/Status sequence is started, data transfer is suspended during the bus 

Register (CSR) architecture; the next 512 bytes, to a register 60 reset, and after the bus reset, the data transfer is restarted in 

of the serial bus; the next 1024 bytes, to a configuration the new network constmction. 

ROM; and the remaining bytes, to a register unique to the [Node-ID Determination Sequence] 

device in a unit space. After the bus reset, the respective nodes start to obtain a 

Generally, for the sake of simplification of bus system node ID so as to construct a new network construction. A 

design for different node types, it is preferable that only the 65 general sequence from the bus reset to node-ID determina- 

initial 2048 bytes are used for the nodes, and as a result, total tion will be described with reference to the flowcharts of 

4096 bytes are used including the initial 2048 bytes for the FIGS. 6 to 8. 
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FIG. 6 is a flowchart showing a sequence from occurrence 
of bus-reset signal to node-ID determination and data trans- 
fer. At step SlOl, the respective nodes always monitor 
occurrence of bus-reset signal. When the bus-reset signal has 
occurred, the process proceeds to step S102, at which to 
obtain a new network construction in a state where the 
network construction has been reset, parent-child relation is 
declared between nodes connected to each other. Step S102 
is repealed until it is determined at step S103 that the 
parent-child relation has been determined among all the 
nodes. 

As the parent-child relation has been determined, the 
process proceeds to step SI 04, at which one "root (node)" is 
determined. At step SI 05, node-ID setting is performed so as 
to provide an ID to the respective nodes. The node-ID setting 
is made in a predetermined order of the nodes. Step S105 is 
repeated until it is determined at step S106 that the ID's have 
been given to all the nodes. 

As the node-ID setting has been completed, since the new 
network construction has been recognized by all the nodes, 
data transfer among the nodes is possible. At step S107, data 
transfer is started, and the process returns to step SlOl, at 
which occurrence of bus-reset signal is monitored again. 

FIG. 7 is a flowchart showing the sequence from the 
monitoring of bus-reset signal (SlOl) to the root determi- 
nation (S104) in detail. FIG. 8 is a flowchart showing the 
node-ID setting (S105 and S106) in detail. 

In FIG. 7, at step S201, the occurrence of bus-reset signal 
is monitored, and as the bus- reset signal has occurred, the 
network construction is reset. Next, at step S202, as a first 
step for re-recognizing the reset network construction, the 
respective devices reset its flag FL with data indicative of 
"leaf (node)". At step S203, the respective devices examine 
the number of ports, i.e., the number of other nodes con- 
nected to them. At step S204, based on the result of 
examination at step S203, the devices examine the number 
of undefined (i.e., parent-child relation has not been 
determined) ports. The number of undefined ports is equal to 
that of the ports immediately after the bus reset, however, 
with the progress of determination of parent-child relation, 
the number of undefined ports detected at step S204 
decreases. 

Only acmal leaf(ves) can declare parent-child relation 
immediately after the bus reset. Whether or not the node is 
a leaf is detected from the number of ports examined at step 
S203; i.e., if the number of ports is "1", the node is a leaf. 
The leaf declares that "this node is a child, and the connected 
node is a parent" at step S205, then terminates the operation. 

On the other hand, a node that detected at step S203 that 
the number of ports is "two or more" is a "branch". 
Immediately after the bus reset, as "undefined ports>l" 
holds, the process proceeds to step S206, at which the flag 
FL is set with data indicative of "branch", then declaration 
of parent-child relation from another node is waited at step 
S207. When the parent-child relation is declared from 
another node, the process returns to step S204 at which the 
branch examines the number of undefined ports. If the 
number of undefined ports is "1", the branch can declare at 
step S205 that "this node is a child, and the connected node 
is a parent" to the node connected to the remaining port. If 
the number of undefined ports is still "two or more", the 
branch waits for declaration of parent-child relation from 
another node at step S207. 

When any one of the branches (or exceptionally leaf(ves) 
which delayed declaring a child) detects that the number of 
undefined ports is "0", the parent-child declaration of the 
overall network has been completed. The only one node that 



)3,737 Bl 

10 

has "0** undefined port, i.e., the parent of aU the nodes, sets 
the flag FL with data indicative of a "root" at step S208. 
Then at step S209, the node is recognized as a root. 
In this manner, the procedure from the bus reset to the 
5 parent-child declaration among aU the nodes in the network 
ends. 

Next, a procedure of providing each node with an ID will 
be described. First, the ID setting is performed at the leaves. 
Then, ID*s are set in numerical order (from node number: 0) 
from leaves-*branches^rooi. 

In FIG. 8, at step S301, the process splits in accordance 
with node type, i.e., leaf, branch or root, based on the data 
set at the flags FL, 

In case of leaf, at step S302, the number of leaves (natural 
number) in the network is set to a variable N. At step S303, 

15 the respective leaves request a node number to the root. If a 
plurality of requests have been made, the root performs 
arbitration at step S304, and provides a node number to one 
node at step S305, while notifies the other nodes of the result 
of acquisition of node -number indicating that the node 

20 number has been failed. 

A leaf that has not obtained a node number (NO at step 
S306) repeats the request for node number at step 8303, On 
the other hand, a leaf that has obtained a node number 
notifies all the nodes of the obtained node number by 

25 broadcasting ID information including the node number. As 
the broadcasting of the ID information has been completed, 
the variable N indicative of the number of leaves is decre- 
mented at step S308. Then, from the determination at step 
S309, the procedure from step S303 to step S308 is repeated 

30 until the variable N becomes "0" in the determination at step 
S309. When ID information on all the leaves have been 
broadcasted, the process proceeds to step S3 10, for setting 
ID'S of branches. 

The ID setting for branches is performed substantially 

35 similar to the ID setting for the leaves. First, at step S310, 
the number of branches (natural number) is set to a variable 
M. At step S311, the respective branches request the root for 
a node number. In response to the requests, the root performs 
arbitration at step S3 12, and provides a node number, 

40 subsequent to the last leaf node number, to a branch at step 
S313, while notifies the other branches of the result of 
acquisition of node-number indicating that the node number 
has been failed. 

A branch that has not obtained a node number (NO at step 

45 S314) repeats the request for node number at step S3 15, On 
the other hand, a branch that has obtained a node number 
notifies all the nodes of the obtained node number by 
broadcasting ID information including the node number. As 
the broadcasting of the ID information has been completed, 

50 the variable M indicative of the number of branches is 
decremented at step S316. Then, from the determination at 
step S317, the procedure from step S311 to step S316 is 
repealed until the variable M becomes "0" in the determi- 
nation at step S3 17. When ID information on all the leaves 

55 have been broadcasted, the process proceeds to step S318, 
for setting the ID of the root. 

At this time, it is only the root that has not obtained a node 
ID. At step S318, the root obtains the smallest number that 
has not been provided to any other node as the node ID of 

60 the root, and at step S319, broadcasts ID information on the 
root. 

As described above, the procedure until the node ID's for 
all the nodes have been set ends. Next, the sequence of node 
ID determination will be described with reference to the 
65 network example shown in FIG. 9, 

In the network in FIG. 9, a node B as a root is directly 
connected to its lower nodes A and C; the node C is directly 
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connected to its lower node D; and the node D is directly 
connected to its lower nodes E and F. The procedure of 
determining this hierarchical structure, the root node and the 
node ID'S will be described below. 

After the bus reset has occurred, to recognize connection 5 
statuses of the respective nodes, parent-child relation is 
declared between ports of directly connected nodes, "par- 
ent" means a node at an upper level and "child" means a 
node at a lower level in the hierarchical structure. In FIG. 9, 
the node that first declared parent-child relation after the bus 10 
reset is the node A. As described above, nodes (leaves) 
where only one port is connected can start declaration of 
parent-child relation. That is, if the number of ports is " 1", 
it is recognized that the node is the end of the network tree. 



[Control Information for Node Management] 

The CSR core as shown in FIG. 3 exists on the register as 
a basic function of the CSR architecmre for node manage- 
ment. FIG, 26A shows the positions and functions of the 
registers. In FIG. 26A, the offset is a relative position from 
"OxFFFFFOOOOOO. 

In the CSR architecture, the register for the serial bus is 
arranged from "OxFFFFF0000200". FIG. 26B shows the 
positions and fimctions of the registers. 

Further, information on node resources of the serial bus is 
arranged from "OxFFFFFOOOOSOO". FIG. 26C shows the 
positions and functions of the registers. 

The CSR architecture has a configuration ROM for rep- 
resenting functions of the respective nodes. The configura- 



i.e., a leaf. The declaration of parent-child relation is started 15 tion ROM has a minimum format and a general format, 



from the leaf which has first taken action among these 
leaves. Thus, a port of the leave node is set as a "child", 
while the port of another node connected to the leave node 
is set as a "parent". In this manner, "child -parent" relation is 
sequentially set between the nodes A and B, between the 20 
nodes E and D, and between the nodes F and D. 

Further, among upper nodes having a plurality of ports, 
i.e., branches, parent-child relation is sequentially declared 
with respect to upper node(s), from the node that first 
received declaration of parent-child relation from the leaf. In ^5 
FIG. 9, first parent -child relation is determined between the 
nodes D and E and between the nodes D and F. Then the 
node D declares parent-child relation with respect to the 
node C, and as a resuh, a relation "child-parent" is set 
between the nodes D and C. The node C, that has received 
the declaration of parent-child relation from the node D, 
declares parent-child relation with respect to the node B 
connected to the other port, thus "child-parent^* relation is set 
between the nodes C and B. 

In this manner, the hierarchical structure as shown in FIG. 
9 is constructed. The node B, that has finally become the 
parent at all the ports, is determined as a root. Note that a 
network has only one root. In a case where the node B that 
has received declaration of parent-child relation from the 
node A immediately declares parent-child relation with 
respect to another node, the other node, e.g., the node C, may 
be the root node. That is, any node may be a root depending 
upon timing of transmitting declaration of parent-child 
relation, and further, even in a network maintaining the same 
construction, a particular node is not always become a root. 

As the root has been determined, the sequence of deter- 
mining the respective node ID's is started. Each node has a 
broadcast fiinction to notify its ID information to all the 
other nodes. ID information includes a node number, infor- 
mation on a connected position, the number of ports, the 
number of ports connected to other nodes, information on 
parent-child relation on the respective ports and the like. 

As described above, the assignment of node numbers is 
started from the leaves. In numerical order, node number=0, 
1, 2, ... is assigned. Then, by the broadcasting of ID 
information, it is recognized that the node number has been 
assigned. 

As all the leaves have obtained a node number, node 
numbers are assigned to the branches. Similar to the assign- 
ment of node numbers to the leaves, ID information is 
broadcasted fi-om the branch that received a node number, 
and finally, the root broadcasts its ID information. 
Accordingly, the root always has the greatest node number. 



arranged from "OxFFFFF0000400". As shown in FIG. 26D, 
the minimum format configuration ROM merely shows a 
vendor ID which is a unique numerical value represented by 
24 bits. 

As shown in FIG. 26E, the general format configuration 
ROM has information on a node. In this case, the vendor ID 
in this format is included in a "root„directory". Further, 
"bus_info_block" and "root&imit_leaves" include unique 
device number including the vendor ID, represented by 64 
bits. The device number is used after network reconstruction 
by bus reset operation, to continue recognition of the node. 
[Serial Bus Management] 

As shown in FIG. 2, the protocol of the 1394 serial bus 
comprises a physical layer 811, a link layer 812 and a 
transaction layer 814. This provides, as the serial bus 
management, a basic function for node management and bus 
resource management, based on the CSR architecture. 

Only one node which performs bus management 
(hereinafter referred to as "bus management node") exists on 
35 the same bus, and provides the other nodes on the serial bus 
with management function which includes cycle master 
control, performance optimization, power source 
management, transmission speed management, construction 
management and the like. 
40 The bus management function briefly divides into a bus 
manager, an isochronous resource manager and a node 
control function. The node control is a management function 
which enables commimication among the nodes in the 
physical layer 811, the link layer 812, the link layer 812, the 
45 transaction layer 814 and an application program by the 
CSR. The isochronous resource manager, which is a man- 
agement function necessary for isochronous-type data trans- 
fer on the serial bus, manages assignment of transfer band- 
width and channel number to isochronous data. For this 
management, after bus initialization, the bus management 
node is dynamically selected from nodes having the isoch- 
ronous resource manager function. 

Further, in a construction without a bus management node 
on the bus, a node having the isochronous resource manager 
55 function performs a part of the bus management such as the 
power source management and cycle master control. 
Further, the bus management is a management function as 
service to provide a bus control interface to an application 
program. The control interface uses a serial-bus control 
60 request (SB_CONTROL.request), a serial-bus event control 
confirmation (SB_CONTROL.confirmation) and a serial - 
bus event indication (SB_EVENT.indication). 

The serial-bus control request is used when an application 



50 



program requires the bus management node to perform bus 
Thus, as the ID setting of the overall hierarchical structure 65 reset, bus initialization, representation of bus-status 
has been completed and the network has been constructed, information, and the like. The serial-bus event control con- 
then the bus initialization is completed. firraation is the result of the serial-bus control request, and 
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is notified from the bus management node to the application 
for confirmation. The serial-bus event control confirmation 
is made as notification of an asynchronously-caused event 
from the bus management node to the application. 
[Data Transfer Protocol] 5 

The data transfer by using the 1394 serial bus simulta- 
neously sends isochronous data (isochronous packet) which 
must be periodically transmitted, and asynchronous data 
(asynchronous packet) which can be transmitted/received at 
arbitrary timing, further, ensures real-time transmission of lO 
isochronous data. In the data transfer, a bus use right is 
requested prior to transfer, and bus arbitration is performed 
to obtain bus use permission. 

In the asynchronous transfer, a transmitting node ID and 
a receiving node ID are sent with transfer data as packet is 
data. The receiving node confirms the receiving node ID, 
i.e., its node ID, receives the packet, and returns an acknowl- 
edge signal to the transmitting node. Thus, one transaction 
is completed. 

In the isochronous transfer, a transmitting node requires 20 
an isochronous channel with a transmission speed, and a 
channel ID is sent with transfer data as packet data. A 
receiving node confirms a desired channel ID and receives 
the data packet. The necessary channel number and trans- 
mission speed are determined by the application layer 816. 25 

These transfer protocols are defined by the physical layer 
811, the link layer 812 and the transaction layer 813. The 
physical layer 811 performs physical and electrical interface 
with the bus, automatic recognition of node connection, bus 
arbitration for a bus use right among nodes, and the like. The 30 
link layer 812 performs addressing, data checking, packet 
transmission/reception and cycle control for isochronous 
transfer. The transaction layer 814 performs processing 
relating to asynchronous data. Here inbe low, the processings 
in the respective layers will be described. 35 
[Physical Layer] 

The bus arbitration in the physical layer 811 will be 
described. 

The 1394 serial bus always performs arbitration of bus 
use right prior to data transfer. The devices connected to the 40 
1394 serial bus respectively relay a signal transferred on the 
network, thus constructing a logical bus-type network trans- 
mitting the signal to aU the devices within the network. This 
necessitates bus arbitration to avoid packet conflict. As a 
result of bus arbitration, one node can transfer data during a 45 
certain period. 

FIGS. lOA and lOB are block diagrams explaining the bus 
arbitration. FIG. lOA shows operation to request a bus use 
right; and FIG. lOB, operation to allow to use the bus. 

When the bus arbitration is started, a single or plurality of 50 
nodes respectively request a bus use right to use the bus to 
its parent node. In FIG. lOA, the nodes C and F request a bus 
use right. The parent node (node A in FIG. lOA) that has 
received the request relays the request by further requesting 
a bus use right to its parent node. The request is forwarded 55 
to a root (node B in FIG. lOA) that finally performs 
arbitration. 

The root that has received the request for bus use right 
determines a node to be provided with the bus use right. This 
arbitration can be performed only by the root. The node that 60 
dominated in the arbitration is provided with the bus use 
right. FIG. lOB shows that the node C has obtained the bus 
use right and the request from the node F has been rejected. 

The root sends a DP (data prefix) packet to nodes lost in 
the bus arbitration so as to notify that their requests have 65 
been rejected. The requests from those nodes are held by the 
next bus arbitration. 
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Thus, the node that obtained the bus use permission starts 
data transfer 

The sequence of the bus arbitration will be described with 
reference to the flowchart of FIG. 11. 

To start data transfer by a node, the bus must be in idle 
status. To confirm that data transfer has been completed and 
the bus is currently in idle status, each node detects a gap 
length of a predetermined idle period (e.g., sub-action gap) 
set in each transfer mode, and it determines whether or not 
the bus is currently in idle status based on the detection 
result. 

At step S401, the node determines whether or not a 
predetermined gap length corresponding to asynchronous 
data or isochronous data to be transferred has been detected. 
So far as the node has not detected the predetermined gap 
length, it cannot request a bus use right to start data transfer, 
accordingly, the node waits until the predetermined gap 
length has been detected. 

When the predetermined gap length has been detected at 
step S401, the node determines whether or not there is data 
to be transferred at step S402. If YES, it issues a signal 
requesting a bus use right to the root at step S403. As shown 
in FIG. lOA, this signal requesting the bus use right is 
relayed by the respective devices in the network, and for- 
warded to the root. If it is determined at step S402 that there 
is no data to be transferred, the process returns to step S401. 

At step S404, if the root has received a single or plurality 
of request signals for the bus use right, it examines the 
number of nodes requesting the bus use right at step S405. 
From the determination at step S405, if the number of the 
nodes requested the bus use right is one, that node is 
provided with bus use permission immediately after the 
requirement. On the other hand, if the number of the nodes 
is more than one, arbitration is performed to determine one 
node to be provided with the bus use right immediately after 
the requirement. The arbitration does not always provide a 
bus use right to the same node, but equally provides a bus 
use right to the respective nodes (fair arbitration). 

The processing at the root branches at step S407 into 
processing for the node dominated in the arbitration at step 
S406, and processing for the other nodes lost in the arbitra- 
tion. In a case where there is one node that requested the bus 
use right, or one node has dominated in the arbitration, the 
node is provided with an permission signal indicative of bus 
use permission at step S408. The node starts data (packet) 
transfer immediately after it receives the permission signal 
(step S410). On the other hand, the nodes lost in the 
arbitration receive a DP (data prefix) packet indicative of 
rejection of the bus use request at step S409. The processing 
for the node that received the DP packet returns to step S401 
to request a bus use right again. Also, the processing for the 
node that completed data transfer at step S410 returns to step 
S401. 

[Transaction Layer] 

The transaction layer includes a read transaction, a write 
transaction and a lock transaction. 

In a read transaction, an initiator (requiring node) reads 
data from a specific address in the memory of a target 
(response node). In a write transaction, the initiator writes 
data into a specific address of the memory of the target. In 
a lock transaction, the initiator transfers reference data and 
update data to the target. The reference data is combined 
with data of the address of the target, into a designation 
address to specify a specific address of the target. Data at the 
designation address is updated by the update data. 

FIG. 27 A shows a request-response protocol with read, 
write and lock commands, based on the CSR architecture in 
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the transaction layer. In FIG. 27 A, the request, notification, 
response and confirmation are service units in the transac- 
tion layer 814. 

A transaction request (TR^DATA^request) is packet 
transfer to a response node; a transaction indication (TR_ 
DATA.indication) is notification of arrival of the request to 
the response node; a transaction response (TR_ 
DATA.response) is transmission of acknowledgment; and a 
transaction confirmation (TR_D ATA. confirmation) is 
reception of acknowledgment. 
[Link Layer] 

FIG. 27B shows services in the link layer 812. The 

services are service units of a link request (LK 

DATA.request) to require packet transfer from the response 
node, a link indication (LK_DArA.indication) indicating 
packet reception to the response node, a link response 
(LK_D ATA. response) as acknowledgment transmitted 
from the response node, a link confirmation (LK_ 
DATA.confirmation) as confirmation of the acknowledg- 
ment transmitted fi-om the response node. One packet trans- 
fer process is called a sub-action including an asynchronous 
sub-action and an isochronous sub -action. Hereinbelow, the 
respective operations of the sub-actions will be described. 
[Asynchronous Sub-action] 

The asynchronous sub- action is asynchronous data trans- 
fer. 

FIG. 12 shows transition in the asynchronous transfer. In 
FIG. 12, the first sub-action gap represents the idle status of 
the bus. At a point where the idle time has become a 
predetermined value, a node which is to perform data 
transfer requests a bus use right, then bus arbitration is 
executed. 

When the use of bus has been allowed by the arbitration, 
data in the form of packet is transferred, and a node which 
receives the data sends a reception acknowledgment code 
ACK as a response, or sends a response packet after a short 
gap called ACK gap, thus the data transfer is completed. The 
code ACK comprises 4-bit information and a 4-bit check- 
sum. The code ACK, including information indicative of 
success, busy or pending status, is immediately sent to the 
data-sender node, 

FIG, 13 shows a packet format for asynchronous transfer. 
The packet has a data area, a data CRC area for error 
correction, and a header area in which a destination node ID, 
a source node ID, a transfer data length and various codes 
are written. 

The asynchronous transfer is one-to-one communication 
from a sender node to a receiver node. A packet sent from 
the sender node is relayed by the respective nodes in the 
network, however, as these nodes are not designated as the 
receiver of the packet, they ignore the packet, then only the 
receiver node designated by the sender node receives the 
packet. 

[Split Transaction] 

The services in the transaction layer 814 are performed as 
a set of transaction request and transaction response, as 
shown in FIG. 27A. If the processings in the link layer 812 
and the transaction layer 814 of the target (response node) 
are performed at a sufiBciently high speed, the request and 
the response are not performed as independent sub-actions 
but as one sub- action in the link layer 812. However, if the 
processing speed of the target is low, the request and the 
response must be processed by independent sub-actions. 
This is called a split transaction. 

FIG. 28A shows an operation example of the split trans- 
action. In FIG. 28A, in response to a write request from a 
controller as an initiator (requiring node), a target returns a 
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pending. The target remrns confirmation information to the 
write request from the controller, thus gains time for data 
processing. When a sufficient period for the data processing 
has elapsed, the target sends a write response to the 
5 controller, thus completes the write transaction. Note that 
another node can perform the operation of the link layer 812 
between the request and response sub-actions. 

FIG. 28B shows transitional statuses of transfer in case of 
the split transaction. In FIG. 28B, a sub-action 1 represents 
the request sub-action; and a sub- action 2, the response 
sub-action. 

In the sub-action 1, the initiator sends a data packet 
indicative of the write request to the target, and the target 
receives the data packet, returns "pending" indicative of the 
confirmation of the above information, as an acknowledge 

15 packet. Then, the request sub-action is completed. 

Then, when a sub-action gap has been inserted, the target 
sends a write response as a data packet with no data, in the 
sub-action 2. The initiator receives the data packet, returns 
a "complete" response as an acknowledge packet. Then, the 

20 response sub-action is completed. 

Note that the period from the completion of the sub- action 
1 to the beginning of the sub-action 2 can be minimized to 
a period corresponding to the sub -action gap, while maxi- 
mized to a period corresponding to a maximum waiting 

25 period set in the nodes. 
[Isochronous Sub-action] 

Isochronous transfer, which can be regarded as the great- 
est feature of the 1394 serial bus is appropriate to multime- 
dia data transfer which requires realtime transfer of, 

30 especially, AV data. 

Further, the asynchronous transfer is one-to-one transfer, 
whereas the isochronous transfer is broadcasting transfer 
from one sender node to all the other nodes. 

FIG. 14 shows transition in the isochronous transfer. The 

35 isochronous transfer is executed on the bus in a predeter- 
mined cycle, called "isochronous cycle". The period of the 
isochronous cycle is 125 jus. A cycle start packet (CSP) 
indicates the start of the isochronous cycle for synchronizing 
the operations of the respective nodes. When data transfer in 

40 a cycle has been completed and a predetermined idle period 
(sub- action gap) has elapsed, a node which is called "cycle 
master" sends the CSP indicative of the start of the next 
cycle. That is, this interval between the issuance of CSP's is 
125 ^. 

45 As channel A, channel B and channel C in FIG. 14, the 
respective packets are provided with a channel ID, so that 
plural types of packets can be independently transferred 
within one isochronous cycle. This enables substantially- 
realtime transfer among the plural nodes. The receiver node 

50 can receive only data with a predetermined channel ID. The 
channel ID does not indicate an address of the receiving 
node, but merely indicates a logical number with respect to 
the data. Accordingly, one packet sent from a sender node is 
transferred to all the other nodes, i.e., broadcasted. 

55 Similar to the asynchronous transfer, bus arbitration is 
performed prior to the packet broadcasting in isochronous 
transfer. However, as the isochronous transfer is not one- 
to-one communication like the asynchronous transfer, the 
reception acknowledgment code ACK used as a response in 

60 the asynchronous transfer is not used in the isochronous 
transfer. 

Further, an isochronous gap (iso gap) in FIG. 14 repre- 
sents an idle period necessary for confirming prior to iso- 
chronous transfer that the bus is in idle status. If the 
65 predetermined idle period has elapsed, bus arbitration is 
performed with respect to node(s) desiring isochronous 
transfer. 
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FIG. ISA shows a packet format for isochronous transfer. 
Various packets divided into channels respectively have a 
data field, a data CRC field for error correction and a header 
field containing information such as a transfer-data length, a 
channel No., various codes and error-correction header CRC 
as shown in FIG. 15B. 
[Bus Cycle] 

In practice, both isochronous transfer and asynchronous 
transfer can be mixedly performed on the 1394 serial bus. 
FIG. 16 shows transition in the isochronous transfer and 
asynchronous transfer mixedly performed on the 1394 serial 
bus. 

The isochronous transfer is performed prior to the asyn- 
chronous transfer because after the CSP, the isochronous 
transfer can be started with a gap (isochronous gap) shorter 
than the idle period necessary for starting the asynchronous 
transfer. Accordingly, the isochronous transfer has priority 
over the asynchronous transfer. 

In the typical bus cycle as shown in FIG. 16, upon starting 
the cycle #m, a CSP is transferred from the cycle master to 
the respective nodes. The operations of the respective nodes 
are synchronized by this CSP, and node(s) that waits for a 
predetermined idle period (isochronous gap) to perform 
isochronous transfer participates in bus arbitration, then 
starts packet transfer. In FIG. 16, a channel e, a channel s and 
a channel k are transferred by the isochronous transfer. 

The operation from the bus arbitration to the packet 
transfer is repeated for the given channels, and when the 
isochronous transfer in the cycle #m has been completed, the 
asynchronous transfer can be performed. That is, when the 
idle period has reached the sub-action gap for the asynchro- 
nous transfer, node(s) that is to perform the asynchronous 
transfer participates in bus arbitration. Note that only if the 
sub-action gap for starting the asynchronous transfer is 
detected, after the completion of isochronous transfer and 
before the next timing to transfer the CSP (cycle synch), the 
asynchronous transfer can be performed. 

In the cycle #m in FIG. 16, the isochronous transfer for 
three channels is performed, and then two packets (packet 1 
and packet 2) including ACK are transferred by the asyn- 
chronous transfer. When the asynchronous packet 2 has been 
transferred, as the next cycle synch point to start the sub- 
sequent cycle m+1 comes, the transfer in the cycle #m ends. 
Note that during the asynchronous or isochronous transfer, 
if the next cycle synch point to transfer the next CSP has 
come, the transfer is not forcibly stopped but continued. 
After the transfer has been completed, a CSP for the next 
cycle is transferred after a predetermined idle period. That is, 
when one isochronous cycle is continued for more than 125 
f4S, the next isochronous cycle is shorter than the reference 
period 125 jus. In this manner, the isochronous cycle can be 
lengthened or shortened based on the reference period 125 
^. 

However, it may be arranged such that the isochronous 
transfer is performed in every cycle, while the asynchronous 
transfer is sometimes postponed until the next cycle or the 
cycle further subsequent to the next cycle, so as to maintain 
realtime transfer. The cycle master also manages informa- 
tion on such delay. 
[FCP] 

In an AV/C protocol, a Function Control Protocol (FCP) 
is provided to control devices on the 1394 serial bus. For 
transmission of control commands and responses in the FCP 
protocol, an asynchronous packet defined by the IEEE 1394 
standards is employed. In the FCP protocol, a node on the 
controller side is called a controller, and a node on the 
controlled side, a target. An FCP packet frame sent from the 
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controller to the target is called an AV/C command frame; an 
FCP packet frame returned from the target to the controller, 
an AV/C response frame. 
FIG. 29 shows a case where a node A is a controller and 

5 a node B is a target. In the register address provided for the 
respective nodes, 512 bytes from "OxOOOOBOO" are assigned 
to a command register; and 512 bytes from "OxOOOODOO" 
are assigned to a response register. Data is written into the 
register of a designated address by a packet frame using the 

10 asynchronous transfer. The relation between the transmis- 
sion of the AV/C command frame by the controller and the 
response with the AV/C response frame by the target is 
called an AV/C transaction. In a general AV/C transaction, a 
target which has received a command frame must send a 

15 response frame to a controller within 100 ms. 

FIG. 30 shows the packet format for the asynchronous 
transfer including an FCP packet frame. A command frame 
or a response frame is inserted into a data area of the 
asynchronous data packet as shown in FIG. ISA, and the 

20 AV/C transaction is performed. 

FIG. 31 shows the structure of the AV/C command frame. 
FIG. 32 shows the structure of the AV/C response frame. As 
the FCP packet frame, an FCP data part is arranged after 
"ctype", "response", "subunit„type" and "subunit_ID" in 

25 the header. 

"ctype" indicates a command type in the command frame, 
with status "CONTROL", "STATUS", "INQUIRY" or 
"NOTIFY". 

"response" indicates a response code in the response 
30 frame, with status "ACCEPTED", "REJECTED", "IN_ 
TRANSITION", "IMPLEMENTED", "CHANGED" or 
"INTERIM". 

Further, "subunit type" indicates the classification of a 

device, and "subunit ID" indicates an instance number. 

35 The FCP data part has an operation code (opcode)+ 
operand (oprand) structure. The target is controlled and the 
AV/C response is performed by using various AV/C com- 
mands. 

The operation code (opcode) in the command frame as 

40 shown in FIG. 31 is one of commands as shown in FIG. 41. 
The respective commands are performed with contents 
according to the command types set at the "ctype". 

A command where the "ctype" designates the status 
"CONTROL" is a control command used for controlling the 

45 target device or setting the target to the content set after the 
operand (oprand). A command where the "ctype" designates 
the status "STATUS" is used for obtaining a status corre- 
sponding to the command. A command where the "ctype" 
designates the status "INQUIRY" is used for inquiring about 

50 contents which can be set by the command. A command 
where the "ctype" designates the status "NOTIFY" is used 
for performing confirmation of the command. 

In each command, necessary content is set at the operand, 
and the command is written into the command frame. 

55 In the operation code of the response frame, one of 
response codes as shown in FIG. 41 is set. Each response has 
an operand corresponding to the response. As information 
indicating whether the execution of the command has been 
normally completed or ended with error, is set at the 

60 operand, error processing can be performed in accordance 
with the operand. 

[Communication Using LOGIN Protocol] 

FIG. 17 shows the interface of the 1394 serial bus in 
comparison with respective layers of an OSI model often 
65 used in a LAN, In the OSI model, a physical layer 1 and a 
data link layer 2 respectively correspond to a physical layer 
811 and a link layer 812 (both shown in FIG. 2) in a lower 
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layer 4 of the 1394 serial bus interface. In the 1394 serial bus 
interface, a transport protocol layer 5 and a presentation 
layer 6 as upper layers correspond to an upper layer 3 of OSI 
model including a network layer, a transport layer, a session 
layer and a presentation layer. Further, a LOGIN protocol 7, 5 
operates between the lower layer 4 and the transport proto- 
col layer 5 of the 1394 serial bus interface. 

In Example 1 in FIG. 17, by providing the LOGIN 
protocol 7 to a device based on a serial bus protocol (SBP-2) 
8 for a peripheral device such as a printer, the peripheral lO 
device uses a protocol based on the protocol SBP-2 to notify 
a target device of data transfer with the target device. In 
Example 2, with respect to a device protocol 9 specialized 
on the 1394 serial bus interface, by providing the LOGIN 
protocol 7 to respective devices, the devices can determine 15 
whether or not the target device supports their protocol, with 
each other 

FIG. 18 shows the basic operation of the LOGIN protocol. 
When a printer device executes a print task 10 from a host 
device, the printer device first selects one of printer proto- 20 
cols A to C for data communication, based on communica- 
tion by the LOGIN protocol 7. Thereafter, the printer device 
performs print data transfer in accordance with the selected 
printer protocol. That is, upon connection between the 
printer device which supports a plurality of printer protocols 25 
and a host device, the printer device fkst judges the transport 
protocol 5 of the host device based on the LOGIN protocol 
7, selects a printer protocol corresponding to the transport 
protocol 5 of the host device, and performs transfer/ 
reception of print data or commands in accordance with the 30 
selected printer protocol, thus performs the print task 10. 

FIG. 19 shows connection status in the 1394 serial bus, 
where devices (PC12, scanner 13 and VCR 14 etc.) with the 
LOGIN protocol 7 are connected to a printer 11 correspond- 
ing to plurality of printer protocols. The printer 11 can 35 
process print tasks from the respective devices by changing 
the printer protocol in accordance with the transport protocol 
5 of a device that requests connection with the printer 
device. 

FIG. 20 shows the flow of log-in operation. 40 
At STEP 1: 

The host device locks a target device (a multi-protocol 
printer in this case). 

The target device examines the capability of the host 
device (including the transport protocol). Note that the 
capability has been stored into a capabihty register 503 
(to be described later) of the host device. 

The target device sets the capability (including the trans- 
port protocol) of the host device. 

At STEP 2: 

Print data is transferred by the protocol determined at the 

STEP 1. 
At STEP 3: 

The host device disconnects the connection with the target 55 
device. 

FIG. 21 shows control/status register (CSR) which is 
prepared by a printer as the target device so that the LOGIN 
protocol is installed, including a lock register 501, a protocol 
register 502 and the capability register 503. These registers 60 
are provided in predetermined addresses in initial unit space 
in the address space of the 1394 serial bus. That is, as shown 
in FIG. 3, within the 48-bit address area provided to the 
devices, "OxFFFFF" in the first 20-bits is called "register 
space", wherein a register (CSR core) as the core of the CSR 65 
architecture is arranged in the first 512 bytes. Note that 
information common to devices connected via the bus is 
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provided in this register space. Further, "0-OxFFFFD" is 
called "memory space", and "OxFFFFE", "private space". 
The private space is an address which can be freely used in 
the device for communication among the devices. 

The lock register 501 indicates a locked status of a 
resource, with a value "0" indicative of log- in enable status, 
and any value but "0", an already-logged-in and locked 
status. The capability register 503 indicates a protocol where 
each bit represents a protocol, with a value "1" bit indicating 
that a corresponding protocol can be set, while a value "0" 
bit, that a corresponding protocol cannot be set. The protocol 
register 502 indicates a currently set protocol. That is, each 
bit of the protocol register 502 corresponds to each bit of the 
capability register 503, and the value of a bit of the protocol 
register 502 corresponding to the set protocol is "1". 

FIG. 22 is a flowchart showing LOGIN processing in the 
host device. 

To start the LOGIN processing, first, the data of the lock 
register 501, the protocol register 502 and the capability 
register 503 of a target device e.g., a printer, to be logged-in, 
is checked by a read transaction. At this time, from the data 
of the capabihty register 503, it is examined whether or not 
the target device supports a protocol used by the host device 
for communication (step S601). If the target device does not 
support the protocol of the host device, the LOGIN process- 
ing is terminated at step S602. 

Further, if the data value of the lock register 501 is not 
"0", it is determined that another device is in logged-in 
status, and the LOGIN processing is terminated. If the data 
value of the lock register 501 is "0", it is determined that 
log-in is currently possible (step S602). 

In case of log-in enable status, the process moves to 
resource lock processing where the log-in is set by writing 
"1" into the lock register 501 of the printer by using a lock 
transaction (step S603). The target device is locked in this 
status, and it is uncontrollable from other devices and the 
register values cannot be changed. 

As described above, in the status where the resource of the 
target device is locked, protocol setting is performed next. 
As the printer as the target device of the present embodiment 
supports a plurality of printer protocols, the printer must be 
informed of the protocol which can be used by the host 
device before it receives print data. In the present 
embodiment, the protocol to be used is notified to the printer 
by setting the corresponding bit of the protocol register 502 
of the printer by a write transaction (step S604). 

At this point, as the protocol used by the host device for 
communication has been notified to the target device and the 
target device is in locked status, the host device that is 
currently logged in the target device performs data (print 
data in this case) transfer (step S605). 

As the data transfer has been completed, the host device 
logs out from the printer by clearing the lock register 501 
and the capability register 503 of the target device (step 
S606). 

FIG. 23 is a flowchart showing the LOGIN processing in 
the printer as the target device. 

The printer generally waits for log-in from a host device. 
As a print request from a host device is started by reading 
data values from the lock register 501, the protocol register 
502 and the capabihty register 503 of the printer, the 
registers must be in read -enable status. This processing will 
be described on the assumption that a host device which is 
to perform printout has locked the printer (step S701). 

The printer waits for notification of an available protocol 
from the host device (step S702). The printer receives the 
notification of available protocol in locked status so as to 
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maintain the protocol register 502 unchanged by another 
device *s request in mid-course of the log-in processing. 

When the available protocol has been assigned (step 
S703), the printer switches its own protocol to the notified 
protocol (steps S704, S706 and S708), and performs com- 5 
munication in accordance with the protocol of the host 
device (steps S705, S707 and S709). 

When the communication has been completed, the printer 
confirms that the lock register 501 and the capability register 
503 have been cleared (step S710), and returns to the log-in 
waiting status (step S701). 

[Example in Consideration of Device without LOGIN 
Protocol] 

FIG. 24 is an explanatory view showing a case in con- 
sideration of a device without the LOGIN protocol 7. 
Compared with the first example as shown in FIG. 18, this 
example is applicable to a device having a protocol D in 
which the LOGIN protocol 7 is not installed. That is, to 
assure the device only corresponding to the conventional 
protocol D (e.g., AV/C protocol) of print operation, as well 
as devices having the LOGIN protocol 7, the printer side has 20 
the protocol D. 

In this case, if the printer recognizes, by a print request 
performed at the beginning of connection, that the host 
device does not correspond to the LOGIN protocol 7, the 
printer tries communication with the host device by using 25 
the protocol D, and if the communication can be established, 
the printer executes the print task 10 in accordance with the 
protocol D. 

FIG. 25 shows the IEEE 1394 serial interface according 
to this example in comparison with the OS I model. Example 30 
3 uses, as a model, an AV device 15 based on the AV/C 
protocol. In the AV device 15, the LOGIN protocol 7 is not 
installed. Example 4 uses, as a model, a scanner 16, in which 
the LOGIN protocol 7 is not installed, but a non-standard 
protocol for scanner is installed. 35 

That is, regarding a device in which the LOGIN protocol 
7 is not installed, if the printer can perform communication 
using the protocol of the device, the printer can perform 
print task from the device. Iliis increases the types of 
devices that can use the printer. 40 
[Direct Print Control] 

Hereinbelow, print procedures in the printer and the image 
providing device will be described. In this case, a Direct 
Print Protocol (DPP), is employed as a protocol to directly 
connect the printer and the image providing device, and 45 
enable the printer to form an image based on image data 
provided from the image providing device. 

The DPP protocol basically comprises a command regis- 
ter (command) for writing a command in the initial unit 
space (the unit space in FIG. 3), a response register 50 
(response) for writing a response to the command, a data 
register (data) for writing transfer data, and a formal register 
(format) for handling format information corresponding to 
data format for each transfer data. 

FIG. 33 shows a register map in which the command 55 
register and the response register are the same as those 
described in FIG. 29. In the following description, the image 
providing device as a controller provides image data to the 
printer as a target and an image is printed based on the image 
data. 60 

A command register 42-1, arranged from a fixed address 
"OxFFFFFOOOOBOO*^ on the printer side, has a 512 byte 
memory space into which the image providing device writes 
various commands for the printer. If the image providing 
device side also has a command register, the printer can 65 
write commands into the register. The command written into 
the command register is called a command frame. 
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A response register 42-2, arranged from fixed address 
"OxFFFFFOOOODOO", has a 512 byte memory space into 
which a response is written with respect to the various 
commands written from the image providing device to the 
printer. If the printer side also has a response register, the 
image providing device can write a response into the reg- 
ister. The response written into the response register 42-2 is 
called a response frame. Note that in FIG. 29, the upper 
address part "OxFFFF" is omitted. 

A data register 42-3, having a default address 
"FFFFF0003000h", is set at an ari)itrary efifecUve address by 
commands "BlockAddress" and "BufferConfig" (commands 
to define the address of the data register). ThG memory space 
of the data register 42-3 is set with a range predetermined by 
commands "BlockSize" and "BufferConfig" (commands to 
define the memory space of the data register). The data 
register 42-3 is used for data transfer between the image 
providing device and the printer. Upon printing, the image 
providing device writes print data for the printer into this 
register. The print data is based on a pre-set image format. 
The data written into the data register 42-3 is called a data 
frame. 

A format register 42-2 is a set of registers corresponding 
to various data formats to be described later. The respective 
registers are used for setting format information necessary 
for the respective data formats. Thai is, the format register 

42- 2 is used for writing the format inforaiation for the 
printer from the image providing device. The format infor- 
mation written into the format register 42-2 is called a 
format frame. 

FIG. 34 shows the flow of frames from the image pro- 
viding device to the printer, i.e., shows the flow of the 
command frame, the response frame, data frame and the 
format frame. The printer performs printing in accordance 
with the frames outputted from the image providing device. 

A command sent from the image providing device to the 
printer is written as a command frame into a command 
register 43-4 of the printer. The command is used for 
printing, as shown in FIG. 41. A response to this command 
is written by the printer into a response register 43-2 of the 
image providing device. The response includes information 
indicating whether or not the command has been properiy 
executed, a remra value to the command and the like. Print 
data sent from the image providing device to the printer is 
written into a data register 43-6 of the printer. Format 
information sent from the image providing device to the 
printer is written as a format frame into a format register 

43- 7 of the printer. 

FIG. 35 shows the construction of the format register 

43- 7. The format register 43-7 includes a read only register 
INQUIRY 44-1 for inquiry and a read/write register 
CONl^ROL/STATUS 44-2 for setting and information 
acquisition. The registers INQUIRY 44-1 and the 
CONTROL/STATUS 44-2 comprise register groups of the 
same structure. That is, the INQUIRY 44-1 has registers 

44- 3 to 44-7, while the CONTROL/STATUS 44-2 has 
registers 44-9 to 44-13. 

More specifically, the format register group includes the 
registers 44-3 and the 44-4 (44-9 and 44-10) constituting a 
print common register group, and the registers 44-5 to 44-7 
(44-11 to 44-13) constituting a printer format register group. 

The common register group, which is a group of registers 
common to all the data formats, has the register GLOBAL 
44-3 (44-9) common to all the printers and the register 
LOCAL 44-4 (44-10) unique to each printer. 

The printer format register group is a group of n registers 
unique to the respective data formats, i.e., the register 



02/20/2004, EAST version: 1.4.1 



us 6,603^ 

23 

formal[l] 44-5 (44-11) to the register fonnat[n] 44-7 (44- 
13). The registers format[l] to format[D] correspond to data 
formats to be described later. One of the printer format 
register group is assigned to each installed data format. 

Note that the address of each format register is provided 5 
to the image providing device as a response to a command 
for setting a data formal. 

FIG. 36 shows the detailed construction of the status 
register 44-8 of the common register group. The status 
register 44-8 comprises a 32 -bit common status register 45-1 
holding a status common to the respective vendor printers 
and a 32-bit vendor specific status register 45-2 holding a 
status defined by each vendor. Further, the extension of the 
vendor specific status register 45-2 is defined as follows, by 
a V flag (vendor status available flag) at the 31th bit of the 
common status register 45-1: 

V flag; 

"O"=not available 
"l"=available 

Further, information held in the common status register 20 

45- 1 is as follows: 

error. warning: status of error, warning and the like 

paper state: status on print sheet 

print state: status on printing situation 

FIG. 37 shows the details of information held in the 25 
register GLOBAL 44-3 (44-9) of the common register 
group. The register GLOBAL 44-3 (44-9) holds information 
common to all the printers having the DPP (Direct Print 
Protocol), i.e., information which does not differ in printer 
type. FIG. 37 shows an example of the information, includ- 30 
ing media-type 46-1 indicative of the type of print medium, 
paper-size 46-2 indicative of a print sheet size, page-margin 

46- 3 indicative of a page margin value, page- length 46-4 
indicative of a page length, page-offset 46-5 indicative of 
page offset, print-unit 46-6 indicative of printer unit 35 
information, color-type 46-7 indicative of the color type of 
printer, bit-order 46-8 indicative of the bit order of data, and 
the like. 

FIG. 38 shows the details of information held in the 
register LOCAL 44-4 (44-10) of the common register group. 40 
The register LOCAL 44-4 (44-10) holds information unique 
to each of the printers having the DPP protocol, i.e., infor- 
mation which differs in printer type. FIG. 38 shows an 
example of the information, including paper 47-1 indicative 
of the type of print sheet of a printer, CMS 47-2 indicative 45 
of a color matching method, ink 47-3 indicative of ink type 
of the printer, e.g., an ink-jet printer. 

FIG. 39 shows the details of information held in the 
register format[l] 44-5. In FIG. 39, information on EXIF 
(Exchangeable Image File Format) as one image data format 50 
is held. The information includes inX-rate 48-1 indicative of 
the rate of X-directional input, inY-rate 48-2 indicative of 
the rate of Y-directional input, outX-rate 48-3 indicative of 
the rale of X-directional output, and outY-rate 48-4 indica- 
tive of the rate of Y-directional output. In this case, printing 55 
is performed by enlarging/reducing given EXIF image data 
in the XY directions in accordance with the respective 
contents of the register. 

FIG. 40 shows the details of information held in the 
register format[2] 44-6. In FIG. 40, information on Raw 60 
RGB as one image format is held. The Raw RGB format has 
a structure to represent each pixel by R (red), G (green) and 
B (blue) data. The information includes inX-rate 49-1 
indicative of the rate of X-directional input, inY-rate 49-2 
indicative of the rate of Y-directional input, outX-rate 49-3 65 
indicative of the rate of X-directional output, outY-rate 49-4 
indicative of the rate of Y-directional output, XY-size 49-5 
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indicative of an XY-directional fixed pixel size, bit-pixel 
49-6 indicative of the number of bits per pixel, X-size 49-7 
indicative of the number of pixels in the X direction, Y-size 

49- 8 indicative of the number of pixels in the Y direction, 
plane 49-9 indicative of the number of color planes, 
X-resolution 49-10 indicative of X-directional resolution, 
Y- resolution 49-11 indicative of Y-directional resolution, 
pixel-format 49-12 indicative of pixel type, and the like. In 
this case, printing is performed by enlarging/reducing given 
Raw RGB format image data and/or changing the resolu- 
tions in the XY directions in accordance with the respective 
contents of the register, further, processing the image data 
based on image size information and the like. 

FIG. 41 shows commands and responses to the com- 
mands. The commands are classified based on several types, 
i.e., "status" type commands relating to status, "control" 
type commands for printer control, "block/buffer** type 
commands for data transfer setting, "channel" type com- 
mands for channel setting, "transfer" type commands relat- 
ing to a transfer method, "format" type commands relating 
to format setting, "log- in" type commands relating to log-in, 
"data" type commands relating to data transfer, and the like. 
Note that the log-in, "log-in" type commands as aforesaid, 
and a command Login, a response LoginResponse, a com- 
mand Logout and a response LogoutResponse described 
later are unrelated to the LOGIN protocol as aforemen- 
tioned. 

More specifically, the "status" type commands include a 
command GetStatus to obtain the status of a printer and its 
response GetStatusResponse 50-1 and the like. 

The "control" type commands include a command Print- 
Reset to reset the printer and its response PrintResetRe- 
sponse 50-2, a command PrintStart to instruct to start 
printing and its response PrintStartResponse 50-3, a com- 
mand PrintStop to instruct to stop printing and its response 
PrintStopResponse 50-4, a command InsertPaper to instruct 
to supply a print sheet and its response InsertPaperResponse 

50- 5, a command EjectPaper to instruct to discharge a print 
sheet and its response EjectPaperResponse 50-6, a command 
CopyStart to instruct to start copying image data and its 
response CopyStart Response 50-7, a command CopyEnd to 
instruct to terminate copying image data and its response 
CopyEndResponse 50-8, and the like. 

The "block/buffer" type commands include a command 
BlockSize to designate a block size and its response Block- 
SizeResponse 50-9, a command BlockAddress to designate 
a block address and its response BlockAdressResponse 
50-10, a command FreeBlock to obtain the number of 
available blocks and its response FreeBlockResponse 50-11, 
a command WriteBlocks to instruct to write data into blocks 
and its response WriteBlocksResponse 50-12, a command 
Bufferconfig to designate buffer information and its response 
BufferConfigResponse 50-13, a command SetBuffer to des- 
ignate to start obtaining data from buffer and its response 
SetBufferResponse 50-14, and the like. 

The "channel" type commands include a command Open- 
Channel to open a channel and its response OpenChannel- 
Response 50-15, a command CloseChannel to close the 
channel and its response CloseChannelResponse 50-16, and 
the like. 

The "transfer" type commands include a command Trans- 
ferMethod to designate a data transfer method and its 
response TransferMethodResponse 50-17 and the like. 

The "formal* type commands include a command Set- 
Format to set a format and its response SetFormatResponse 
50-18 and the like. 

The "login" type commands include a command Login to 
perform log-in and its response LoginResponse 50-19, a 
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command Logout to perform log-out and its response available data transfer method of the printer by the com- 

LogoutResponse 50-20, a command Reconnect to perform mand TransferMethod and the response TransferMethod- 

reconnection and its response ReconneciResponse 50-21, Response in the command type INQUIRY (steps S600-1 and 

and the like. S600-2), and obtains and sets a data transfer method cur- 

These commands are written into a command frame. 5 rently set at the printer, by the command TransferMethod 

Further, the "data" type commands include commands and the response TransferMethodResponse of the command 

WriteBlock 50-22 and WriteBuflfer 50-23 to write data, a type CONTROL/ST>\TUS (steps 5600-3 and S600-4). 

command PullBuffer 50-24 to read data, and the like. These in any of the above five type of transfer methods, the 

commands are written/read with respect to a data frame, and control commands for flow control are based on the FCP 

there have no responses corresponding to these commands. 10 protocol as a protocol for controUing a device on the 1394 

The image providing device sets a value corresponding to serial bus. The transfer of control command by the FCP 

each of the various commands as shown in FIG. 41 at the protocol is always performed by an asynchronous write 

operation code (opcode), and writes the command into the transaction, in both transmission and response, 

command register 43-4 of the printer. Thus, the command is piG. 45 shows a register map of registers necessary for 

executed by the printer. The response to the command has 15 the transfer method 1 and the transfer method 2, in address 

the same value as that of the command. The printer sets the space of the 1394 serial bus. In the present embodiment, a 

response at the operation code of the response frame as node on the controller side is the image providing device 

shown in FIG. 32, and writes the frame into the response (controller in the FCP protocol), and a node on the controlled 

register 43-2 of the image providing device. By the side is the printer (target in the FCP protocol), 

response, the image providing device receives the result of 20 Both image providing device and printer have a command 

execution of the command. register (601-1 and 601-7) with offset of 512 bytes from 

HG. 42 shows the image data formats supported by the "OxOBOO" and a response register (601-2 and 601-8) with 

DPP protocol. The printer must support Raw image data of offset of 512 bytes from "OxODOO" in the register space, 

at least one of these formats. Further, the printer can support These registers are based on the FCP protocol and the AV/C 

other pliu"al formats as optional formats. 25 commands. 

FIG. 43 shows the flow of format setting processing. First, jhe flow control is made by writing the command frame 

the image providing device sends the command SetFormat 601-4 and the response frame 601-5 into the command 

(INQUIRY) to the printer at step S500, and the printer register (601-1 and 601-7) and the response register (601-2 

returns the SetFormatResponse at step S501. The image and 601-8), respectively. Further, for print data transfer, a 

providing device obtains the address of the INQUIRY reg- 30 dedicated data frame is defined. That is, a data register 

ister of the printer by the returned response. (601-3 and 601-9) for a block size is provided from offset 

Next, the image providing device sends the command "0x3000" in the register space, and print data is transferred 

SetFormat (CONTROL/STATUS) to the printer at step by writing a data frame 601-6 into the data register (601-3 

5502, and the printer returns the SetFormatResponse at step and 601-9). Note that the block size is 512 bytes, for 

5503. The image providing device obtains the address of the 35 example. 

CONTROIVSTATUS register of the printer by the returned piG. 46 shows a data packet frame comprising a data 

response, header 602-1, a data payload 602-2 and the like. 

The image providing device reads the INQUIRY register piG. 47 shows the structure of the data header 602-1. In 

of the printer at steps S504-1 to S504-m, and obtains the the data header 602-1, upper 8 bits are assigned to a block 

format supported by the printer and set items of the format. 40 count area 603-1, and lower 8 bits, to a future reserve area 

Next, the image providing device reads the STATUS/ 603-2 . The block count area 603-1 is interaally used by the 

CONTROL register of the printer at steps S505-1 to S505-n, target (printer) to count the number of blocks transferred at 

obtains the set values of the format, then writes data into the one block transfer. Note that as the block count area 603-1 

STATUS/CONTROL register of the printer, thus sets the has 8 bits, it takes a value "0" to "255". 

format. 45 pjQ 4^ shows data packet frame processing in the printer 

The data transfer in the DPP protocol uses the foUowiag in block transfer. A data packet received by the printer is first 

two packets. written into a data register 604-1 of the printer. The printer 

Control command packet for flow control has buffers (604-2 to 604-5) of the same size of that of the 

Packet for data transmission data packet. The data packet written in the data register 

In the present embodiment, the following five types of 50 6 04-1 is sequentially moved to these buffers (604-2 to 

data transfer methods are used in accordance with the 604-5). Note that the number of the data buffers is preferably 

difference among data transmission methods and flow con- 255, the maximum block count value, but it may be a value 

trols. In any method, control commands for the flow control less than 255. The respective buffers correspond to block 

are based on the FCP protocol. However, The control count values. A data packet when the block count value is 

commands are not limitted to the FCP protocol. 55 "0** is stored into a buffer of Block[0]; and a data packet 

Transfer method 1: Response model when the block count value is "1" is stored into a buffer of 

Transfer method 2: Simplified response model Block[l]. The data header 602-1 is removed from the data 

Transfer method 3: PUSH large buffer model packets stored in the buffers (604-2 to 604-5), and the data 

Transfer method 4: PULL buffer model packets are developed in a memory space 604-6 of the 

Transfer method 5: Isochronous model 60 printer. 

In actual transfer, one of the above methods is selected [Transfer Method 1] 

and set in a procedure similar to the format setting procedure The transfer method 1 as the response model defines a 

as shown in FIG. 43. Note that as shown in FIG. 44, the data packet frame for data transmission, provides a data 

command TransferMethod and the response TransferMetho- register, performs flow control by control commands, while 

dResponse are employed. 65 transfers print data by a write transaction. 

FIG. 44 shows the flow of data-transfer method setting FIG. 49 shows commands and responses FreeBlock in the 

processing. The image providing device obtains a currently transfer method 1. In the transfer method 1, prior to data 
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transfer, the image providing device uses the commands and 
responses FreeBlock to obtain information indicating the 
number of data packets to be transferred. 

The image providing device transfers the FreeBlock com- 
mand by a write transaction (step S605-1), and the printer 
returns an ACK packet indicative of the acknowledgment of 
the transaction (step S605-2). The printer returns the Free- 
BlockResponse to notify a FreeBlockCount (step S605-3) 
which is the number of currently available blocls, and the 
image providing device returns an ACK packet indicative of 
the acknowledgment of the transaction (step S605-4). 

FIG. 50 shows the flow of data transfer in the transfer 
method 1 . The image providing device logs in the printer by 
the command and response Login of the DPP protocol (steps 
S606-1 and S606-2), and sets a format to be used for data 
transfer by using the above-described format register group 
(step S606-3). Thereafter, the image providing device opens 
a logic channel by the command and response OpenQiannel 
(steps S606-4 and S606-5). Next, data transfer is started, and 
print data is transferred in the data packet format as shown 
in FIG, 46. Further, the packet transfer is performed in 
correspondence with the number of blocks the same as the 
number of data buffers on the printer side, as shown by 
references 604-2 to 604-5 in FIG. 48, as one cycle. 

In the transfer method 1, the print data is transferred as 
follows. The image providing device obtains the FreeBlock- 
Count of the printer by the command and response Free- 
Block (steps S606-6 and S606-7), and sequentially transfers 
data packets of the same number as that of the 
FreeBlockCount, by the command WriteBlock (step S606- 
8). Note that the command WriteBlock is used for transfer- 
ring print data packets from the data register 601-3 of the 
image providing device to the data register 601-9 of the 
printer. Note that there is no response corresponding to the 
command WriteBlock, and the printer returns an ACK 
packet to confirm that the data packets have been stored into 
the data register 601-9. 

Then, block transfer is performed by repeating packet 
transfer, with the commands WriteBlock of the same number 
of the FreeBlockCount and ACK packets corresponding to 
the commands until all the series of print data has been 
outputted from the image providing device, and between the 
respective block transfers, the FreeBlockCount of the printer 
is obtained by the command and response FreeBlock. 

When the print data transfer has been completed, the 
image providing device closes the logic channel by the 
command and response Close Channel (steps S606-10 and 
S606-11), and logs out from the printer by the command and 
response Logout of the DPP protocol (steps S606-12 and 

5606- 13). 

[Transfer Method 2] 

The transfer method 2 as the simplified response model 
performs data transfer in the same procedure as that of the 
transfer method 1 except the method to obtain the Free- 
BlockCount. 

FIG. 51 shows the flow of data transfer in the transfer 
method 2. The image providing device logs in the printer by 
the command and response Login of the DPP protocol (steps 

5607- 1 and S607-2), and sets a format to be used for data 
transfer by using the above -described format register group 
(step S607-3). Thereafter, the image providing device opens 
a logic channel by the command and response OpenChannel 
(steps S607-4 and S607-5). Next, data transfer is started, and 
print data is transferred in the data packet format as shown 
in FIG. 46. Further, the packet transfer is performed in 
correspondence with the number of blocks the same as the 
number of data buffers on the printer side, as shown by 
references 604-2 to 604-5 in FIG. 48, as one cycle. 
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In the transfer method 2, the print data is transferred as 
follows. The image providing device obtains the FreeBlock- 
Count of the printer of the printer by the command Write- 
Blocks and response WriteBlockResponse (steps S607-6 

5 and S 607-7), Note that the response at step S607-7 is of the 
INTERIM type for performing the acquisition of the Free- 
BlockCount only by the response from the printer side. The 
image providing device sequentially transfers data packets 
of the same number as the obtained FreeBlockCount, by the 

10 command WriteBlock (step S607-8), and the printer returns 
the above-described ACK packet (607-9). Then, block trans- 
fer is performed by repeating packet transfer by the com- 
mands WriteBlock of the same number as the FreeBlock- 
Count and ACK packets corresponding to the commands 

15 until all the series of print data has been outputted from the 
image providing device. Note that at the second cycle and 
the subsequent cycles in the block transfer, the FreeBlock- 
Count is notified to the image providing device by the 
WriteBlocksResponse from the printer, at the end of each 

20 block transfer cycle (step S607-10). The WriteBlocksRe- 
sponse is of the CONTINUE type used for continuing the 
acquisition of the FreeBlockCount only by the response 
from the printer. 
When the print data transfer has been completed, the 

25 image providing device closes the logic channel by the 
command and response CloseChannel (steps S607-11 and 
S 607-12), and logs out from the printer by the command and 
response Logout of the DPP protocol (steps S 607-13 and 

5607- 14). 

30 [Method to Obtain FreeBlockCount] 

Hereinbelow, the method to obtain the FreeBlockCount, 
which is the difference between the transfer method 1 and 
the transfer method 2, will be described in detail. 

FIG. 52 shows the commands and responses FreeBlock in 

35 the transfer method 1 at steps S 606-6 and S606-7, in detail, 
including the ACK packets of the write transaction omitted 
in FIG. 50. In this case, both initiator device (image pro- 
viding device) and the target device (printer) perform pro- 
cessing of the fink layer and transaction layer at a relatively 

40 low Speed. 

When the image providing device writes the command 
FreeBlock into the command register by a write transaction 
(step S608-1), the above-described ACK packet indicative 
of "pending" is returned from the link layer of the printer 

45 (step S608-2). Next, the image providing device sends a 
command FreeBlock with no data (step S608-3), and 
receives an ACK packet indicative of "complete" from the 
printer (step S608-4). Thus, one write transaction ends. 
Next, the printer returns the FreeBlockResponse. Similar 

50 to the command FreeBlock at step S608-1, the FreeBlock- 
Response is written as a response including the FreeBlock- 
Count into the response register (step S608-5). An ACK 
packet indicative of "pending" is returned from the link 
layer of the image providing device (step S608-6). Then, the 

55 printer sends the FreeBlockResponse with no data (step 

5608- 7), and receives an ACK packet indicative of "com- 
plete" (step S608-8). Thus, one write transaction ends. 

On the other hand, in the transfer method 2, only the 
FreeBlockResponse from the printer is used to obtain the 
60 FreeBlockCount at the second and the subsequent cycles in 
the print data block transfer. Accordingly, the FreeBlock- 
Count is obtained only by the operation at steps S608-5 to 
S608-8. 

The acquisition of the FreeBlockCount is necessary at 
65 each cycle of block transfer. Accordingly, in the transfer 
method 2, the number of packets transferred on the bus can 
be less than that in the transfer method 1. 
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FIG. 53 shows the commands WriteBlock in the transfer 
method 1 and the transfer method 2 in detail. As the 
command WriteBlock requires no response, commands in 
this procedure are sent in the order, the WriteBlock (step 
S609-1), an ACK packet indicative of "pending" (step 5 
S609-2), the WriteBlock with no data (step S609-3) and an 
ACK packet indicative of "complete" (step S609-4). The 
length of the procedure is the half of that in the case where 
commands and responses are transferred. This performs data 
transfer at a relatively high speed even if the processings in lO 
the link layer and the transaction layer are performed at a 
relatively slow speed. 

FIG. 54 shows the command WriteBlock in the transfer 
method 1 and the transfer method 2 in detail, in a case where 
the processings in the link layer and the transaction layer are 15 
performed at a suflBciently high speed. In this case, com- 
mands in this procedure are sent in the order, the WriteBlock 
(step S610-1), and an ACK packet indicative of "complete" 
(step S610-2). This performs more efiBcient data transfer. 

FIG. 55 shows the flow of WriteBlock error processing 20 
upon occurrence of bus reset. In this case, the bus reset 
occurs at transfer of n-th (=0-255) packet at one block 
transfer cycle. In a write transaction, a failure of data packet 
transfer is indicated by an ACK packet, however, error upon 
bus reset cannot be delected. Then, in the present 25 
embodiment, error processing is performed in the following 
procedure. That is, in a case where the FreeBlockCount is 
obtained (step S611-1), then the WriteBlock is sent n times 
(step S611-2 to S6U-6), if bus reset occurs at this time (step 
S611-7), the image providing device again sends the 30 
WriteBlock[n] immediately before the bus reset (step S611- 
8), and thereafter, continues the processing (steps S611-9 to 
S6U-14). 

[Transfer Method 3] 

FIG. 56 shows the construction of command registers, 35 
response registers and data registers of the image providing 
device and the printer, in the PUSH large buffer model. 

The commands and responses between the image provid- 
ing device and the printer based on the FCP protocol are 
executed by operation of writing a command frame 65-7, as 40 
command request data, from a command register 65-1 of the 
image providing device into a command register 65-4 of the 
printer, and operation of writing a response frame 65-8, as 
response data, from a response register 65-5 of the printer 
into a response register 65-2 of the image providing device. 45 

Further, different from the FCP protocol, a data frame 
65-9 is used in one-directional operation of writing image 
data from a data register 65-3 of the image providing device 
into a data register 65-6 of the printer by using a write 
transaction. so 

FIG. 57 shows the flow of operation of the PUSH buffer 
model between the image providing device and the printer. 

Note that the commands Login, Logout, OpenQiannel 
and CloseChannel and format setting are similar to those in 
the above-described transfer method 1, therefore, detailed 55 
explanations of the commands and the format setting will be 
omitted. 

In FIG. 57, the image providing device inquires about the 
buffer area of the printer by the command BufferConfig 
indicating "INQUIRY" (step S1701). The printer returns the 60 
buffer size and buffer address by the BufferConfigResponse 
(step S1702). 

Next, the image providing device sets the buffer size and 
the buffer address of the printer into which data is written, 
by the command BufferConfig indicating "CONTROL" 65 
(step S1703). The printer returns the BufferConfigResponse 
indicating that the setting has been completed (step S1704). 
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Next, the image providing device notifies the printer that 
data transfer is to be started, by using the command Set- 
Buffer indicating "NOTIFY" (step S1705). The printer 
returns the "INTERIM" SetBufferResponse indicating that 
the printer is prepared for the present to receive the data 
(step S1706), to let the image providing device start data 
transfer. Then, the printer notifies the image providing 
device that the data transfer to the initially set buffer area has 
been completed, by using the SetBufferResponse indicating 
"CONTINUE" (step S1709). 

The command WriteBuffer at step S1707 indicates data 
frame writing by the image providing device. In this 
operation, data is sequentially written into the buffer address 
set in the printer. 

A response WriteTransaclionResponse at step S1708 indi- 
cates a response packet upon isochronous transfer of data 
frame. As described above, if the data input speed of the 
printer is sufficiently high, the processing can be completed 
by using an acknowledgment of one write transaction, 
however, if data input takes time, independent responses 
occur as a split transaction. 

Step S1710 indicates processing of transferring a plurality 
of data frames. That is, the data is transferred by a series of 
transactions to an area having the buffer size set by using the 
command BufferConfig. The data transfer method using a 
series of transactions is called a "PUSH data transfer 
method" or abbreviated to a "PUSH method". 

FIG. 58 shows the structure of a data packet in the data 
frame. As the data can be written by directly addressing the 
buffer of the printer, a data packet 67-1 does not include a 
header and the like. 

FIG. 59 shows the relation between the data register and 
the buffer of the printer. Data written in a data register 68-1 
is directly written into the address of a memory space 68-2 
of the printer, designated by "BufferAddress" determined by 
an offset "Destination_Offset". As the offeet value is incre- 
mented by a data length indicated by "Data_Length", the 
data is continuously written within the area indicated by 
"BufferSize" by repeatedly writing the data into the series of 
buffer addresses. 
[Transfer Method 4] 

FIG. 60 shows the construction of the command registers, 
the response registers and the data registers of the image 
providing device and the printer, in the PULL buffer model. 

The commands and responses between the image provid- 
ing device and the printer, based on the FCP protocol, are 
executed by operation of writing a command frame 69-7, as 
command request data, from a command register 69-1 of the 
image providing device into a command register 69-4 of the 
printer, and operation of writing a response frame 69-8, as 
response data, from a response register 69-5 of the printer 
into a response register 69-2 of the image providing device. 

Further, different from the FCP protocol, a data frame 
69-9 is used in one-directional operation of reading image 
data from a data register 69-3 of the image providing device 
into a data register 69-6 of the printer by using a read 
transaction. 

FIG. 61 shows the flow of operation of the PULL buffer 
model between the image providing device and the printer. 
Note that the commands Login, Logout, OpenChannel and 
CloseChannel and format setting are similar to those in the 
above-described transfer method 1, therefore, detailed 
explanations of the commands and responses BufferConfig 
and SetBuffer (steps SI 711 to S1714), which are the same as 
those in the above-described transfer method 3, will be 
omitted. 

In FIG. 61, the image providing device notifies the printer 
that data transfer can be started by using the command 
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SetBuffer indicating "NOTIFY" (step S1715). The printer number of FreeBlock is the number of block buffers ensured 

returns the "INTERIM" SetBufferResponse indicating that in block units in the memory space of the printer. The 

the printer is prepared to receive data (step SI 716) for the ErrorStatus is used to notify the image providing device of 

present, and let the image providing device start data trans- error information in previous block transfer. Note that the 

fer. Then, the printer notifies the image providing device that 5 printer always returns "normal" as the EnorStatus to the first 

data transfer into the initiaUy set buffer area has been command FreeBlock after the logic channel has been 

completed, by using the SetBufferResponse indicating opened. 

"CONTINUE" (step S1719') Then, the image providmg device block*transfers print 

The printer requires a read transaction by a command data by an isochronous transaction (step S514). At tW^ 

PullBufferRequest (step S1717). TTien the image providing lO the image providing device sends data packets of the number 

J * fj;u r»,iir>«:n corresponding to the FreeBlockCount. 

devic^ transfe^ data by a PuUBufferResponse packet (step ^ ^^^.^^ ^^^^^^ 

S1718), thus data is sequentially wntten into the buffer p^eeBlock to the printer (step S51 5). The printer returns the 

address set in the printer. FreeBlockResponse (step S516). If the ErrorStatus of the 

Step S1720 mdicates processing of transferrmg a plurality response indicates "abnormal", i.e., if an error has occurred 

of data frames. That is, the data is transferred by a series of is ^t the previous block transfer, the image providing device 

read transactions to the area having the buffer size set by sends the data transferred at step S514 again (step S517). 

using the command BufferConfig. The data transfer method Thereafter, the processing at steps S515 to S517 is repeated 

using a series of transactions is called a "PUSH data transfer until the data transfer has been normally completed. Further, 

method" or abbreviated to a "PUSH method". if the ErrorStatus indicates "normal", the image providing 

FIG, 62 shows the relation between the data register and 20 device sends data packets of the number indicated by the 

the buffer of the image providing device. Data is read from FreeBlockCount included in the FreeBlockResponse (step 

a memory space 72-2 of the image providing device desig- S517). 

nated by "Buffer Address" determined by an offset Note that the printer determines whether or not an error 

"Destination_Offset" set in the data register 71-1. As the bas occurred by referring to the block count of the header in 

oflset value is incremented by a data length indicated by 25 transferred data (FIG. 64). Further, if the FreeBlockCount is 

"Data__Length", the data is continuously read from the area greater than the number of blocks of data to be transferred, 

indicated by "BufferSize" by repeatedly writing the data into ^he image providing device sends dummy packets of a 

the series of buffer addresses. corresponding to the excessive blocks. 

[Transfer Method 51 Then, data transfer by an isochronous transaction is 

In the transfer method 5 as the Isochronous model, the 30 f P^^'?'' ^' series of print data have been outputted 

. ^ J , r i_ • u • • irom the image providmg device, 

print data transfer by usmg the asynchronous transaction in ^^^^ data transfer has been completed, similar to the 

the above-described transfer method lis replaced with prmt above-described transfer method 1, the image providing 

data transfer by using an isochronous transaction. Note that device closes the logic channel by the command and 

the structure of a data packet is the same as that shown in response CloseChannel (steps S518fl and S519), and logs 

FIGS. 46 and 47. Further, the data packet frame processing 35 out from the printer by the command and response Logout 

in the printer upon block transfer is the same as that in FIG. of the DPP protocol (steps S520 and S521). 

48. As described above, according to the present 

Note that according to the present transfer method, data embodiment, the image providing device and the printer are 

transfer can be made at predetermined time by using an directly connected by using the 1394 serial bus or the like, 

isochronous write transaction. 40 and image data is directly sent from the image providing 

Further, in the block transfer, if an error occurs upon device to the printer, so that the printer prints an image based 

transferring print data for one page at once, it takes a long on the image data. 

time to re-transfer the print data for one page. However, if Further, as control commands and print data are separated, 

print data is transferred in more fine block units, e.g., the embodiment provides an efficient data transfer methods 

print-band units of an ink-jet printer, print data re -transfer 45 in the 1394 serial bus or the Uke. 

due to the occurrence of error can be efficiently performed. Further, the embodiment provides a data transfer method 

FIG. 63 shows command registers and response registers which recovers a transfer error in the 1394 serial bus. 

for flow control. The image providing device writes a Further, the embodiment provides a data transfer method 

command frame into a command register 75-3 of the printer in which determination whether or not data can be written 

by an asynchronous write transaction. The printer writes a 50 into the register area is unnecessitated by notification of the 

response frame to the command into a response register 75-2 number of available blocks of a register area for data 

of the image providing . device by an asynchronous write transfer, and the overhead necessary for the determination is 

transaction. removed. Further, the embodiment provide an eflScient data 

FIG. 64 shows the flow of print processing. First, similar transfer method since as data for the notified number of 

to the above-described transfer method 1, the image provid- 55 available blocks is transmitted and received, 

ing device sends the command Login to the printer (step Further, according to the embodiment, a data transfer 

S507). The printer returns the LoginResponse (step S508), method appropriate to a transfer destination device can be 

thus connection is established. selected from a plurality of data transfer methods. 

Next, similar to the above -described transfer method 1, Further, the embodiment provides a data transfer method 

the image providing device performs format setting (step 60 which avoids degradation of transfer eflBciency due to com- 

S509), and sends the command OpenChannel to the printer mand transmission upon data transfer from a host device to 

(step S510). The printer returns the OpenChannelResponse a target device, by only using a command instructing to start 

(step S511), thus a logic channel is opened. data transmission and a response to the command, i.e.. 

Then, the image providing device sends the command transmitting no command after the start of the data transfer. 

FreeBlock to the printer (step S512). The printer returns the 65 Further, the embodiment provides a data transfer method 

FreeBlockResponse (step S513). The FreeBlockResponse based on the PUSH method or PULL method upon data 

includes the number of FreeBlock and ErrorStatus. The transfer between a host device and a target device. 
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Further, the embodiment provides a data transfer method 
which performs isochronous transfer and asynchronous 
transfer in the same transfer procedure upon data transfer 
between a host device and a target device. 

Further, the embodiment provides a data transfer method 5 
in which, when a transfer error occurs at a certain part of 
data in isochronous transfer, performs re-transfer the part of 
data where transfer the error has occurred, upon data transfer 
between a host device and a target device. 

Further, the embodiment provides a data transfer method 
which performs proper data transfer even if bus reset occurs 
in data transfer between a host device and a target device. 

Further, a peripheral device such as a printer which 
utiUzes the above data transfer methods can be provided. 
[Modification of Embodiment] 

Note that the above embodiment has been described in a 
case where a network is constructed by using the IEEE 1394 
serial bus, however, the present invention is not limited to 
the 1394 serial bus. For example, the present invention is 
applicable to a network constructed by using an arbitrary 
serial interface such as a Universal Serial Bus (USB). 20 

In the above-described embodiment, commands and 
responses to the commands based on the FCP protocol are 
employed, and information is set at the response and notified 
to the host device. However, a method of mapping a register 
on a memory as the characteristic feature of the IEEE 1394 25 
memory bus model can be considered. 

In this case, a command is executed by writing command 
data into a command register assigned to a specific address 
of the memory. Similarly, a response is indicated by reading 
data at a response register assigned to a specific address of 30 
the memory. 

Accordingly, when the target device recognizes that a 
command has written into a command register, the target 
device executes the command, and writes the result of the 
execution of the command and information into a response 35 
register. The host device which has written the command 
into the command register reads the response register of the 
target device and obtains the result of the execution of the 
command and information. 

Ilius, the present invention can be realized by using 40 
registers in the memory bus model. 

In the above -described embodiment, discussing examples 
which have a taget device as a printer. However, the target 
device of the present invention is not limitted to the printer. 
That is, some device recording image data such as a display 45 
apparatus and a storage apparatus applies to the target device 
of the present invention. 

The present invention can be applied to a system consti- 
tuted by a plurality of devices (e.g., host computer, interface, 
reader, printer) or to an apparatus comprising a single device 50 
(e.g., copy machine, facsimile). 

Further, the object of the present invention can be also 
achieved by providing a storage medium storing program 
codes for performing the aforesaid processes to a system or 
an apparatus, reading the program codes with a computer 55 
(e.g., CPU, MPU) of the system or apparatus from the 
storage medium, then executing the program. 

In this case, the program codes read from the storage 
medium realize the functions according to the embodiments, 
and the storage medium storing the program codes consti- 60 
tutes the invention. 

Further, the storage medium, such as a floppy disk, a hard 
disk, an optical disk, a magneto -optical disk, CD-ROM, 
CD-R, a magnetic tape, a non -volatile type memory card, 
and ROM can be used for providing the program codes. 65 

Furthermore, besides aforesaid functions according to the 
above embodiments are realized by executing the program 



,737 Bl 

34 

codes which are read by a computer, the present invention 
includes a case where an OS (operating system) or the like 
working on the computer performs a part or entire processes 
in accordance with designations of the program codes and 
realizes functions according to the above embodiments. 

Furthermore, the present invention also includes a case 
where, after the program codes read from the storage 
medium are written in a fimction expansion card which is 
inserted into the computer or in a memory provided in a 
function expansion unit which is connected to the computer, 
CPU or the like contained in the function expansion card or 
unit performs a part or entire process in accordance with 
designations of the program codes and realizes functions of 
the above embodiments. 

The present invention is not limited to the above embodi- 
ments and various changes and modifications can be made 
within the spirit and scope of the present invention. 
Therefore, to appraise the public of the scope of the present 
invention, the following claims are made. 

What is claimed is: 

1. A data transmission method of host and target devices 
connected by a serial bus, said method comprising the steps 
of: 

sending a command from the host device to the target 
device; 

returning a response from the target device to the host 
device; 

transferring data of a predetermined unit, which com- 
prises a predetermined number of blocks, by isochro- 
nous transfer from the host device to the target device 
if it is determined, based on the response, that a transfer 
error has not occurred; and 

retransferring, if an occurrence of a transfer error is 
determined, a part of the data of the predetermined unit 
transferred when the transfer error occurred, based on 
buffer information included in the response, indicating 
a number of blocks receivable by a receiving buffer of 
the target device, regarding the data of the predeter- 
mined unit, and 

wherein, in the serial bus, a first transfer method to 
transfer the data of the predetermined unit by the 
isochronous transfer, by a predetermined communica- 
tion cycle, and a second transfer method to transfer the 
data of the predetermined unit by asynchronous 
transfer, in accordance with necessity, are available. 

2. The method according to claim 1, wherein, at said 
transferring step, the data is divided into a plurality of 
blocks. 

3. The method according to claim 1, further comprising 
the step of detecting occurrence of a transfer error based on 
a block count included in data to be transferred. 

4. The method according to claim 1, wherein data transfer 
is performed based on a block count included in the 
response. 

5. The method according to claim 1, wherein, if a number 
of blocks of data to be transferred is less than a block count 
included in the response, at least one dummy block is 
transferred. 

6. The method according to claim 1, wherein the serial bus 
is a bus adapted to or based on IEEE 1394-1995 standards. 

7. The method according to claim 1, wherein the serial bus 
is a bus adapted to or based on Universal Serial Bus 
standards. 

8. The method according to claim 1, wherein the host 
device provides image data. 

9. The method according to claim 1, wherein the target 
device forms a visible image based on image data on a print 
medium. 
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10. The method according to claim 1, wherein the target 
device forms a visible image based on image data on a 
display medium. 

11. The method according to claim 1, wherein the target 
device stores an image data into a storage medium. 

12. An image processing apparatus comprising: 
communication means for performing communication 

with a target device by the data transmission method of 
claim 1; and 

transmission means for transmitting image data to the 
target device via said communication means. 

13. An image processing apparatus comprising: 
communication means for performing communication 

with a host device by the data transmission method of 
claim 1; and 

processing means for processing image data received 
from the host device via said commimication means, 

14. A data transmission apparatus connected to a serial 
bus, comprising: 

command transmission means for transmitting a com- 
mand to a target device; 

reception means for receiving a response returned from 
the target device; 

transfer means for transferring data of a predetermined 
unit, which comprises a predetermined number of 
blocks, by isochronous transfer to the target device if it 
is determined, based on the response, that a transfer 
error has not occmred; and 

retransfer means for retransferring, if an occurrence of a 
transfer error is determined, a part of the data of the 
predetermined unit transferred when the transfer error 
occurred, based on buffer information included in the 
response, indicating a number of blocks received by a 
re-receiving buffer of the target device, regarding the 
data of the predetermined unit, 

wherein, in the serial bus, a first transfer method to 
transfer the data of the predetermined unit by the 
isochronous transfer, by a predetermined commimica- 
tion cycle, and a second transfer method to transfer the 
data of the predetermined unit by asynchronous 
transfer, in accordance with necessity, are available. 

15. The apparatus according to claim 14, wherein, in data 
transfer by said transfer means, the data is divided into a 
plurality of blocks. 

16. ITie apparatus according to claim 14, wherein the 
target device detects occurrence of a transfer error based on 
a block count included in data to be transferred. 

17. The apparatus according to claim 14, wherein data 
transfer is performed based on a block count included in the 
response. 

18. The apparatus according to claim 14, wherein said 
transfer means transfers at least one dummy block if a 
number of blocks of data to be transferred is less than a block 
count included in the response. 

19. The apparatus according to claim 14, wherein the data 
transferred by said transfer means is image data. 

20. A data transmission apparatus connected to a serial 
bus, comprising: 

reception means for receiving a command and data sent 
from a host device, said reception means receiving data 
of a predetermined unit, which comprises a predeter- 
mined nmnber of blocks; 

transmission means for sending a response to the host 
device; and 

detection means for inserting information indicative of 
occurrence of a transfer error into the response if an 
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occurrence of a transfer error is detected in a data 
transfer, so that the host device retransmits a part of the 
data of the predetermined unit transferred when the 
transfer error occurred, based on buffer information 
included in the response indicating a number of blocks 
receivable by a re-receiving buffer of said reception 
means, regarding the data of the predetermined unit, 
wherein, in the serial bus, a first transfer method to 
transfer the data of the predetermined unit by isochro- 
nous transfer, by a predetermined communication 
cycle, and a second transfer method to transfer the data 
of the predetermined unit by asynchronous transfer, in 
accordance with necessity, are available. 

21. The apparatus according to claim 20, wherein the data 
sent from the host device is divided into a plurality of blocks. 

22. The apparatus according to claim 20, wherein said 
detection means detects an occurrence of a transfer error 
based on a block count included in the data sent from the 
host device. 

23. The apparatus according to claim 20, wherein the data 
is sent from the host device based on a block count included 
in the response. 

24. The apparatus according to claim 20, wherein the host 
device transfers at least one dummy block if a number of 
blocks of data to be transferred is less than a block count 
included in the response. 

25. The apparatus according to claim 20, further com- 
prising formation means for forming on a print medium a 
visible image based on the data received by said reception 
means. 

26. The apparatus according to claim 20, further com- 
prising formation means for forming on a display medium a 
visible image based on the data received by said reception 
means. 

27. The apparatus according to claim 20, further com- 
prising storing means for storing data received by said 
reception means into a storage medium. 

28. A data transmission system for transferring data 
through a serial bus, comprising: 

communication means for sending a command from a 
host device to a target device, and sending a response 
from the target device to the host device; 

transfer means for transferring data of a predetermined 
unit, which comprises a predetermined number of 
blocks, by isochronous transfer from the host device to 
the target device if it is determined, based on the 
response, that a transfer error has not occurred, and 

retransferring, if an occurrence of a transfer error is 
determined, a part of the data of a predetermined unit 
transferred when the transfer error occurred, from the 
host device to the target device, based on buffer infor- 
mation included in the response, indicating a number of 
blocks receivable by a re -receiving buffer of the target 
device, regarding the data of the predetermined unit, 

wherein, in the serial bus, a first transfer method to 
transfer the data of the predetermined unit by the 
isochronous transfer, by a predetermined commimica- 
tion cycle, and a second transfer method to transfer the 
data of the predetermined unit by asynchronous 
transfer, in accordance with necessity, are available. 

29. The system according to claim 28, wherein, in data 
transfer by said transfer means, the data is divided into a 
plurality of blocks. 

30. The system according to claim 28, wherein the target 
device detects an occurrence of a transfer error based on a 
block count included in data transferred from the host 
device. 
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31. The system according to claim 28, wherein data 
transfer is performed based on a block count included in the 
response. 

32. The system according to claim 28, wherein said 
transfer means tramfers at least one dummy block from the 
host device to the target device, if a number of blocks of data 
to be transferred is less than a block count included in the 
response. 

33. A data transmission method of host and target devices 
connected by a serial bus, said method comprising the steps 
of: 

sending a command from the host device to the target 
device; 

returning a response to the command from the target 
device to the host device; 

transferring data of a predetermined unit, which com- 
prises a predetermined number of blocks, from the host 
device to the target device, based on the response; and 

retransferring, if a bus reset has occurred, a part of the 
data of the predetermined unit transferred when the bus 
reset occurred, based on buffer information included in 
the response, indicating a number of blocks receivable 
by a re -receiving buffer of the target device, regarding 
the data of the predetermined unit, 

wherein, in the serial bus, a first transfer method to 
transfer the data of the predetermined unit by isochro- 
nous transfer, by a predetermined communication 
cycle, and a second transfer method to transfer the data 
of the predetermined unit by asynchronous transfer, in 
accordance with necessity, are available. 

34. The method according to claim 33, 

wherein the bus reset is a process to initialize a commu- 
nication system constructed using the serial bus, and 

wherein, after initialization, the host device re transfers the 
part of the data of the predetermined unit. 

35. The method according to claim 34, wherein connec- 
tion construction of devices connected to the serial bus is 
recognized by the initialization. 

36. The method according to claim 33, wherein, if a bus 
reset has occurred, the host device retransfers data trans- 
ferred immediately before occurrence of the bus reset or the 
data comprising the predetermined number of blocks trans- 
ferred when the bus reset occurred. 

37. The method according to claim 33, wherein the host 
device generates image data, and the host device transfers 
the generated image data, divided by a predetermined unit. 

38. The method according to claim 33, wherein the target 
device forms a visible image based on the image data 
transferred from the host device. 

39. The method according to claim 33, wherein the target 
device stores image data transferred from the host device. 

40. ITie method according to claim 33, wherein the host 
device transfers the data of the predetermined unit by the 
asynchronous transfer, in accordance with necessity. 

41. The method according to claim 33, wherein the serial 
bus is a bus adapted to or based on IEEE 1934-1995 
standards. 

42. The method according to claim 33, wherein the serial 
bus is a bus adapted to or based on Universal Serial Bus 
standards. 

43. An image processing apparatus comprising: 
communication means for performing communication 

with a target device by the data transmission method of 
claim 33; and 

transmission means for transmitting image data of a 
predetermined unit to the target device. 
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44. An image processing apparatus comprising: 
communication means for communicating with a host 

device by the data transmission method of claim 33; 
and 

^ processing means for processing the image data of the 
predetermined unit received from the host device. 

45. A data transmission apparatus connected to a serial 
bus, comprising: 

command transmission means for transmitting a com- 
mand to a target device; 

reception means for receiving a response to the command 
returned from the target device; 

transfer means for transferring data of a predetermined 
15 unit, which comprises a predetermined number of 
blocks, to the target device, based on the response; and 

retransfer means for, if a bus reset has occurred; retrans- 
ferring a part of the data of the predetermined unit 
transferred when the bus reset occurred, based on buffer 
20 information included in the response, indicating a num- 
ber of blocks receivable by a re -receiving buffer of the 
target device, regarding the data of the predetermined 
unit, 

wherein, in the serial bus, a first transfer method to 
25 transfer the data of the predetermined unit by isochro- 
nous transfer, by a predetermined communication 
cycle, and a second transfer method to transfer the data 
of the predetermined unit by asynchronous transfer, in 
accordance with necessity, are available. 

46. The apparatus according to claim 45, 

wherein the bus reset is a process to initialize a commu- 
nication system constructed using the serial bus, and 

wherein, after initialization, said retransfer means retrans- 
fers the part of the data of the predetermined unit. 

47. The apparatus according to claim 46, wherein con- 
nection construction of devices connected to the serial bus is 
recognized by the initialization. 

48. The apparatus according to claim 45, wherein the data 
of the predetermined unit comprises a predetermined num- 
ber of blocks. 

49. The apparatus according to claim 48, wherein, if a bus 
reset has occurred, said retransfer means retransfers data 
transferred immediately before occurrence of the bus reset 
or the data comprising the predetermined number of blocks 
transferred when the bus reset occurred. 

50. The apparatus according to claim 45, wherein the host 
device generates image data, and the host device transfers 
the generated image data, divided by a predetermined unit, 

51. The apparatus according to claim 45, wherein the data 
of the predetermined unit is transferred by the asynchronous 
transfer, in accordance with necessity. 

52. The apparatus according to claim 45, wherein the 
serial bus is a bus adapted to or based on IEEE 1394-1995 
standards. 

53. The apparatus according to claim 45 , wherein the 
serial bus is a bus adapted to or based on Universal Serial 
Bus standards. 

54. A data transmission apparatus connected to a serial 
bus, comprising: 

command reception means for receiving a command sent 

from a host device; 
transmission means for transmitting a response to the 

command, to the host device; 
65 transfer means for transferring data of a predetermined 

unit, which comprises a predetermined number of 

blocks, to the host device, based on the response; and 
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re -reception means for, if a bus reset has occurred, 
re-receiving a part of the data of the predetermined unit 
transfened when the bus reset occurred, based on buffer 
information included in the response, indicating a num- 
ber of blocks receivable by a buffer of said re-receptioo 5 
means, regarding the data of the predetermined unit, 

wherein, if a bus reset has occurred, said re -reception 
means re-receives data received immediately before 
occurrence of the bus reset or data comprising the 
predetermined number of blocks received when the bus 10 
reset occurred. 

55. The apparatus according to claim 54, 

wherein the bus reset is a process to initialize a commu- 
nication system constructed using the serial bus, and 

wherein, after initialization, said re-reception means 
re -receives the part of the data of the predetermined 
unit. 

56. The apparatus according to claim 55, wherein con- 
nection construction of devices connected by the serial bus 
is recognized by the initialization. 

57. The apparatus according to claim 54, wherein said 
data transmission apparatus forms a visible image based on 
the image data received from the host device. 

58. The apparatus according to claim 54, wherein the 
serial bus is a bus adapted to or based on IEEE 1394-1995 
standards. 

59. The apparatus according to claim 54, wherein the 
serial bus is a bus adapted to or based on Universal Serial 
Bus standards, 

60. A data transmission apparatus connected to a serial 
bus, comprising: 

command reception means for receiving a command sent 
from a host device; 

transmission means for transmitting a response to the 35 
command, to the host device; 

transfer means for transferring data of a predetermined 
unit, which comprises a predetermined number of 
blocks, to the host device, based on the response; and 

re -reception means for, if a bus reset has occurred, ^ 
re-receiving a part of the data of the predetermined unit 
transferred when the bus reset occurred, based on the 
buffer information included in the response, indicating 
a number of blocks receivable by a buffer of said 
re-reception means, regarding the data of the predeter- 
mined unit, 

wherein, in the serial bus, a first transfer method to 
transfer the data of the predetermined unit by isochro- 
nous transfer, by a predetermined communication 
cycle, and a second transfer method to transfer the data 
of the predetermined unit by asynchronous transfer, in 
accordance with necessity, are available, 

61. The apparatus according to claim 60, wherein the host 
device transfers the data of the predetermined unit by the 
asynchronous transfer, in accordance with necessity. 

62. A data transmission system for transferring data 
through a serial bus, comprising: 

communication means for transmitting a command from 
a host device to a target device, and returning a 
response to the command from the target device to the 
host device; 

transfer means for transferring data of a predetermined 
unit, which comprises a predetermined number of 
blocks, between the host and target devices, based on 65 
the response; and 
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retransfer means for, if a bus reset has occurred, re trans- 
ferring a part of the data of the predetermined unit 
transferred when the bus reset occurred, based on buffer 
information included in the response, indicating a num- 
ber of blocks receivable by a re-receiving buffer of the 
target device, regarding the data of the predetermined 
unit, 

wherein, in the serial bus, a first transfer method to 
transfer the data of the predetermined unit by isochro- 
nous transfer, by a predetermined communication 
cycle, and a second transfer method to transfer the data 
of the predetermined unit by asynchronous transfer, in 
accordance with necessity, are available. 

63. A computer program product comprising a computer 
readable medium storing computer program codes for 
executing a method of data transmission between host and 
target devices connected by a serial bus, said product 
comprising process procedure codes for: 

sending a command from the host device to the target 
device, and sending a response from the target device 
to the host device; 

transferring data of a predetermined unit, which com- 
prises a predetermined number of blocks, by isochro- 
nous transfer from the host device to the target device 
if it is determined, based on the response, that a transfer 
error has not occurred; and 

retransferring, if an occurrence of a transfer error is 
determined, a part of the data of the predetermined unit 
transferred when the transfer error occurred, from the 
host device to the target device, based on buffer infor- 
mation included in the response, indicating a number of 
blocks receivable by the re-receiving buffer of the 
target device, regarding the data of the predetermined 
unit, 

wherein, in the serial bus, a first transfer method to 
transfer the data of the predetermined unit by the 
isochronous transfer, by a predetermined communica- 
tion cycle, and a second transfer method to transfer the 
data of the predetermined unit by asynchronous 
transfer, in accordance with necessity, are available. 

64. A computer program product comprising a computer 
readable medium storing computer program codes for 
executing a method of data transmission between host and 
target devices connected by a serial bus, said product 
comprising process procedure codes for: 

transmitting a command from the host device to the target 
device, and returning a response to the command from 
the target device to the host device; 

transferring data of a predetermined unit, which com- 
prises a predetermined number of blocks, between the 
host and target devices, based on the response; and 

retransferring, if a bus reset has occurred, a part of the 
data of the predetermined unit transferred when the bus 
reset occurred, based on buffer information included in 
the response, indicating a number of blocks receivable 
by a re-receiving buffer of the target device, regarding 
the data of the predetenmined unit, 

wherein, in the serial bus, a first transfer method to 
transfer the data of the predetermined unit by isochro- 
nous transfer, by a predetermined communication 
cycle, and a second transfer method to transfer the data 
of the predetermined unit by asynchronous transfer, in 
accordance with necessity, are available. 
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